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.

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.

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:

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.

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.

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.

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

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.

Definimos Modelo de Negocio…

Dado que un proyecto de desarrollo es un esfuerzo que conjuga recursos humanos, equipos, espacio de oficina, garantías comerciales, junto a otros muchos gastos y costos de todo tipo, es necesario que como parte del Proceso se encuentren actividades especificas orientadas a garantizar el retorno de la inversión y la viabilidad financiera del proyecto.

Es en este concepto donde encontramos la expresión Modelo de Negocio. Con ella queremos hacer referencia a los mecanismos que hemos dispuestos para asegurarnos ese deseado retorno de la inversión. Como parte del mismo, tomamos en cuenta aspectos tales como: la contratación con los clientes, los productos ofrecidos, los recursos financieros involucrados, entre otros; considerando en cada caso, los gastos generados y los ingresos obtenidos.

Un Modelo de Negocio es un plan financiero por lo que ha de abarcar un tiempo lo suficientemente largo como para que refleja la realidad; y es también es una decisión estratégica, por lo que tendrá una parte de inversión y una apuesta económica.

Lo que se puede recomendar aquí, es que durante la fase de concepción del proyecto se construya un Caso de Negocio, que es la instancia particular del Modelo de Negocio que seguimos, y que solo se siga a la Fase de Elaboración en el caso en que este estudio dé buenas expectativas de ganancia. En cualquier caso, como cada Modelo de Negocio tiene sus propios retos y riesgos conocidos, tomaremos de él, mucha información útil para la construcción del Plan de Riesgos.

Nos estamos viendo.

Disciplina de Diseño

El diseño es el acto de disponer las cosas, de manera que al estas desarrollarse se llegue a los resultados deseados. La intención del diseño es crear estructuras temporales o intermedias, que al paso del tiempo den lugar a la forma definitiva y deseada.

En Ingeniería del Software, llamamos Disciplina de Diseño a las actividades que determinan la disposición de las clases, archivos ejecutables, código, datos, etc. que forman la estructura estática del sistema, de manera tal -lo digo de nuevo- de permitir a la hora de la ejecución, que el sistema exhiba la funcionalidad requerida.

Dado que el Análisis pone en descubierto las instancias que al colaborar dan lugar a la funcionalidad, nosotros podemos definir sobre esta idea que el Diseño se encarga de encontrar una relación de clases -elementos estáticos- que al entrar en ejecución nos permite instanciar lo visto por el análisis.

Finalmente, en palabras técnicas, como para el Glosario:

Disciplina de Diseño. Es la encargada de realizar los Casos de Uso al nivel del Modelo de Diseño; a fin de establecer las estructuras intermedias que conforme a las restricciones de la tecnología utilizada, son necesarias para instanciar en tiempo de ejecución aquello que sea necesario para satisfacer el requisito.

La cual espero, sea una definición entendible a la luz de lo dicho primero.

Disciplina de Análisis

Llamamos análisis a la actividad mental de ver al todo como una colección de partes. La ejercemos cuando vemos un fenómeno o problema y somos capaces de reconocer sus elementos constituyentes.

En Ingeniería del Software, se habla de la Disciplina de Análisis cuando por medio de artefactos o documentos, se elabora una descripción de los elementos que el análisis arroja sobre el problema.

Si trabajamos con UML[1] nos podemos servir de los diagramas de colaboración y secuencia, entre otros, para representar las partes que se han visualizado; documentando así la forma en que estas trabajan en el todo.

Utilizando un lenguaje si se quiere excesivamente técnico, es posible decir que:

Disciplina de Análisis: es la encargada de realizar los Casos de Uso al nivel de Modelo de Análisis; a fin de documentar las instancias que al colaborar, proveen la funcionalidad requerida en el Caso de Uso original.

O en palabras más cristianas, se dice que dentro del desarrollo de un sistema, la Disciplina de Análisis pone en claro las objetos -de momento, sin tipo determinado- que colaboran para dar a lugar la funcionalidad deseada; a lo cual, se llama Escenario de Análisis o como no, Realización de Caso de Uso al Modelo de Análisis.

En un proyecto, no es necesario realizar un análisis detallado de cada Caso de Uso. En su lugar, se dejara esta actividad solo para aquellos casos en que no se entienda por completo lo que se requiere. Por lo que no es imposible encontrar proyectos que se hayan saltado por completo el análisis… simplemente es un proyecto en que cada uno de los involucrados se encontraba en terreno familiar.

Seguiremos explorando el tema próximamente.