Category Archives: Desarrollo de Software

Publicaciones diversas sobre temas generales de Ingeniería y desarrollo de software.

Categorización de Defectos de Software: una propuesta

En la dinámica actual y especialmente en ciudades con alto grado de urbanización, nuestras vidas literalmente dependen del software. Los sistemas y las aplicaciones (en sus diferentes presentaciones) forman parte de nuestro día a día y una porción significativa de nuestar labor productiva, social, personal y hasta familiar pasa cotidianamente (como información) a través de ellas.

La certeza del correcto funcionamiento del software es algo que generalmente damos por sentado; sin embargo, siendo el éste (todavía) producto de humanos, también está sujeto a errores los cuales pueden tener diferentes fuentes y muy diversos efectos, desde cálculos erróneos, funcionalidad inhabilitada, imposibilidad de guardar cambios, hasta fuga de información. Dependiendo del contexto, tales efectos pueden pasar desapercibidos o poner en riesgo la vida de las personas.

Por esta razón la gestión de defectos (estén atentos sobre una próxima publicación sobre este tema) es un proceso fundamental en el desarrollo de software. Una parte de dicha gestión consta de analizar el orígen y causas del defecto (pronto viene una publicación sobre RCA) para entender cómo se gestó, qué impacto tuvo, cuál fue el proceso para su solución y cómo se pueden reducir errores similares en el futuro.

En mi experiencia con proyectos de software de diversas industrias, arquitecturas, tecnologías, plataformas y magnitudes, he compilado y desarrollado una clasificación de defectos relativos a su orígen que propicia las siguientes ventajas:

  • Ecualiza los defectos: Agrupa los defectos por causas, independientemente de sus consecuencias o la magnitud de su impacto.
  • Apoya en su priorización: permite realizar una comparativa de volúmenes entre categorías.
  • Aprovecha lecciones aprendidas: sirve como apoyo en el análisis de la ejecusión de medidas generales tanto correctivas como preventivas, por ejemplo relacionadas con las mejores prácticas asociadas a la categoría o que hayan sido aplicadas con anterioridad en defectos de la misma cateogoría.
  • Promueve procesos de mejora: sirve como base en la generación o derivación medidas correctivas o preventivas adicionales sobre una base probada y común.
  • Democratiza su gestión: al considerar que los defectos se producen por la interacción de los miembros de un equipo y no solo de un rol particular.

Las categorías propuestas obedecen a tres premisas fundamentales:

  • Atender a las causas del defecto y no a las consecuencias (causalidad)
  • Generar el menor traslape posible entre las categorías (segregación)
  • Procurar el agrupamiento de todos los defectos (universalidad)

Como veremos en la discusión posterior, en la práctica pueden ocurrir casos en los que sea difícil realizar clasificación del defecto, es principalmente por esta razón que la lista propuesta no pretende ser exahustiva ni definitiva, sino servir como guía para que cada equipo desarrolle su propio esquema de modo que se ajuste al contexto y las condiciones de sus proyectos.

Categorías para la clasificación defectos

Defectos causados por datos: este tipo de defectos tiene su origen en la fuente donde se almacena la información para su extracción y posterior procesamiento y/o despliegue. Por ejemplo: datos almacenados en formato incorrecto o con valores inapropiados, recursos (imágenes, documentos, tipografías) erroneos o no disponibles, etc.

Defectos causados por lógica de programación: este tipo de defectos causan problemas en la funcionaliad del software y son relativos a una mala implementación del algoritmo, o el proceso que puede estar relacionada con la falta de análisis de los datos de entrada, una intepretación incorrecta del requerimiento (procesamiento de datos y la salida del proceso), errores en la codificación (inicialización de variables, mal posicionamiento de elementos de inicio o fin de bloques de código, etc).

Defectos causados por procesos del SDLC: este tipo de defectos son causados por la falta de seguimiento (o la inexistente definición) de procesos relacionados con la generación y despliegue del código del software; por ejemplo, el seguimiento de estándares de codificación, el despliegue de elementos relacionados en conjunto (código adicional, archivos de configuración, recursos asociados o cambios en el esquema de bases de datos), ejecusión de pruebas (unitarias, de humo o de regresión), etc.

Defectos causados por Requerimientos incompletos: este tipo de defectos están relacionados con ambiguedades u omisiones en los requerimientos que dejan a la interpretación del lector aspectos importantes sobre la implementación y funcionalidad deseada. Por ejemplo en procesos ágiles es muy común que no se cumpla con el “Definition of Done” para las historias de usuario, y en equipos no muy maduros tiende a causar conflictos entre la intepretación de quien va a desarrollar la funcionalidad respecto a quien la va a probar. Una manera de identificar estos defectos es cuando en las discusiones entre los desarrolladores y los ingenieros de calidad aparecen fraces como: “es que yo pensé”, “lo que yo había entendido es”, o “como no decía, asumí”.

Defectos causados por las herramientas o el ambiente del SDLC: hay ocasiones en los que un defecto surge aún cuando tanto el código como los datos son correctos y se siguieron los procesos de manera correcta. Muchos de ellos son causados por inconsistencias en los ambientes en los que se despliega el código, configuraciónes erróneas, conflicto en versiones de software requerido, uso de herramientas no estandarizadas para el desarrollo o la promoción del código, etc.

Defectos Inválidos: esta categoría no obedece a una causa sino a la necesidad de agrupar los “defectos defectuosos”, es decir, aquellos defectos que luego de una revisión terminaron siendo funcionalidad esperada o se descarta su atención por no obedecer a una especificación o inclusive por ser trivial en el contexto. En muchos casos estos defectos son eliminados de la bitácora; sin embargo, es importante mantenerlos como evidencia tanto del esfuerzo invertido por quien lo registró como de que los ingenieros de pruebas también cometen errores.

Defectos Removidos: esta categoría no obedece a una causa sino a la necesidad de agrupar aquellos defectos que por cualquier causa no sean atendidos por el equipo que los generó, sino que son extraídos para su atención por otro equipo. En muchas ocasiones los equipos pierden visibilidad del destino de este tipo de defectos por lo que es importante mantener evidencia de su existencia y (en la mayoría de los casos) procurar su seguimiento para la correcta actualización de su estado (por ejemplo si está todavía abierto, en progreso o cerrado)

En efecto, se pudiera pensar (especialmente si comulga con la frase “todo se reduce a las matemáticas”), que las categorías pudieran reducirse también solo a “procesos, procesos, procesos”. En la práctica, el desarrollo de software es mucho más complejo. Esta visión reduccionista toma en cuenta que establecimiento y consecuente seguimiento de procesos previene fallas subsecuentes, de modo que si un defecto se presenta es por la falta de seguimiento o definición de un proceso.

Existen diversos modelos de desarrollo de softare que funcionan bajo esa premisa pero requiere que el equipo y los procesos sean maduros, y por lo tanto el número de defectos inyectados debría ser menor de manera proporcinal. Sin embargo, en el mundo ágil del desarrollo de software, simplemente no es el caso.

El contexto diverso de cada proyecto de software hace que la clasificación de un defecto dentro de una de las categorías propuestas pueda ser relativamente sencilla o muy compleja. Un ejemplo en el que se observa la complejidad de la clasificación es el siguiente:

Imagine un escenario donde una página web tiene un error en un texto legal donde algunas palabras cuentan con símbolos no alfanuméricos. Al ser un texto relativamente estático, de primera instancia se puede pensar que es un defecto de contenido relacionado con los datos pero al verificar el almacenamiento no se observan los símbolos mencionados.

Una investigación más profunda revela que el texto fue extraido desde la herramienta de gestión de requerimientos e insertada en el archivo de almacenamiento mediante un proceso copy-paste; sin embargo, el programa de edición de textos utilizado para actualizar el archivo de almacenamiento del texto resultó incompatible con el formato UTF, por lo que aparentemente el texto visualmente es correcto pero su representación binaria en el archivo causa la aparición de símbolos cuando se extrae el texto para su inserción en la página web.

Si existe una política definida para el equipo sobre el uso de herramientas para los procesos de extracción de texto, entonces es un defecto causado por no seguir los procesos del SDLC; de lo contrario es un defecto causado por las herramientas del SDLC y como medida de mitigacíón se establecería la política mencionada.

La dinámica del universo del desarrollo de software es en realidad más caótica e inexpugnable de lo que parece, por lo que para mí cualquier elemento de guía o apoyo puede hacer la diferencia entre encallar o llegar a buen pruerto.

Desarrollate, desarrollando!

Deja tus comentarios en Linkedin o en Twitter.

FinShape para Web ya está disponible

Después de un buen rato de no publicar en este espacio, decidí hacerlo con una excelente noticia 🙂

¡La versión de Web de FinShape ya está disponible!

FinShape es un software de uso libre para la medición de aletas dorsales de delfines, cuyo propósito es ayudar en la investigación de dichas especies sirviendo como apoyo para la foto identificación de individuos y poder asociarlos a groupos y regiones para estudiar aspectos como patrones de migración, su dinámica poblacional, hábitos, etc.

La iniciativa de este software fue de mi hermano Eduardo Morteo como uno de los resultados de su tesis de Mastría en 2001. Originalmente el software era una aplicacion computadoras Windows y tuvo un éxito moderado en la comunidad; sin embargo, debido a que las tecnologías con las que fue desarrollado se fueron haciendo obsoletas, la aplicación poco a poco fue cayendo en desuso.

A principios de 2017, durante una reunión informal nos llamó la atención conocer que había grupos de usuarios en la comunidad cinetífica que continuaban usando la aplicación original y que para ese exclusivo propósito mantenían corriendo una versión de Windows XP. Fue entonces (y en coincidencia con la curiosidad de un grupo de estudiantes universtarios por explorar tecnologías innovadoras) que surgió la idea de migrar la funcionalidad de FinShape hacia una plataforma Web.

Nuestra jornada dió inicio en abril de 2017, haciendo varias sesiones para explicar la funcionalidad, aportar ideas sobre cómo implementarla y sobre qué tecnologías, definiendo la arquitectura etc. El trayecto fue lento principalmente por la disponibilidad de tiempo de los participantes así como la curva de aprendizaje de técnicas, procesos y tecnologías nuevas. Pudimos experimentar con la creación de módulos con diferentes funcionalidades (que finalmente no formaron parte de la liberación de la aplicación) pero de las que sin lugar a dudas aprendimos mucho.

Hoy, tengo el ernorme gusto de presentar a la comunidad el fruto de este gran esfuerzo el cuál está disponible en FinShape.morteo.mx.

Quiero termnar esta publicación agradeciendo el enorme esfuerzo, la paciencia, pero sobre todo la confianza de todos aquellos quienes a lo largo de más de 3 años participaron y colaboraron en el equipo para hacer realidad esta idea.

NodeJS en Ubuntu 14.4 con apt-get

Para aquellos que quieran instalar NodeJS en Ubuntu 14.4

Nota: se asume que tienen acceso una terminal y la contraseña para utilizar el comando “sudo”

Abra una terminal bash y ejecute los siguientes comandos en orden:
sudo apt-get install nodejs [enter]
sudo apt-get install npm [enter]
sudo npm install -g express [enter]
sudo npm install -g express-generator [enter]
sudo ln -s /usr/bin/nodejs /usr/bin/node [enter]

Si al utilizar el npm install obtienes un “Error: EACCES, mkdir” ejecuta los siguientes comandos:

sudo chown -R $USER:$GROUP ~/.npm
sudo chown -R $USER:$GROUP ~/tmp

Y ahora… disfruta nodejs.

Actualizacion:

para instalar paquetes debes user npm link:

sudo npm install -g link

Dentro del folder de la aplicación para instalar express por ejempo:

sudo npm link express
npm start

Contratos para Desarrolladores

Si bien, el título de esta publicación puede ser engañoso, me permito hacer la correspondiente aclaración para evitar confusiones: en efecto, no voy a mostrar ni a referir ejemplos del texto de los documentos legales para realizar proyectos de software (que en realidad puenden ser encontrados en otras partes); en cambio, realizaré una breve comparación entre estos documentos y los programas de cómputo; la cual  espero que sea de interés y utilidad para  mis colegas desarrolladores.

Como todos los lenguajes de programación, también todos los contratos legales tienen una estructura y sintaxis. Del mismo modo, en esencia, hay una serie de elementos requeridos que se aplican a todos y cada uno los contratos. Estos elementos se pueden comparar a elementos tomados del código fuente de un programa informático, específicamente los parecidos al lenguaje C.

Antes de comenzar, me gustaría indicar que así como es una buena práctica para los desarrolladores el nombrar a su proyecto de programación de acuerdo al objetivo que persigue y utilizar alguna convensión de denominación para nombrar los archivos, variables y procedimientos con base en el dominio del problema al que se adscribe; comparativamente, existen convenciones acerca de cómo se denominan los contratos en función de su finalidad y todos ellos utilizan términos legales comunes relacionados con el contexto específico de su aplicación.

Ahora, independientemente del orden de aparición de los elementos siguientes, en relación con sus contrapartes de programación, los elementos comparativos antes mencionados se describen a continuación:

  • Bibliotecas: En el espíritu de evitar tanto reinventar la rueda como las repeticiones innecesarias (fomentando la reutilización), los lenguajes de programación hacen uso de bibliotecas de código (o precompiladas) a través de declaraciones de uso o de inclusión. Estas declaraciones son comparables a citar las leyes o reglamentos en los contratos que se eligen en función de la finalidad del mismo y también, por lo general, se encuentran al principio del documento.
  • Declaración e inicialización de variables: Estos elementos definen los tipos de datos de las variables y constantes que se utilizarán, y los preparan con valores adecuados. Esto mismo ocurre con las cláusulas primarias o “Declaraciones” en un contrato. Lo anterior, incluye lo que en la jerga legal se conoce como la definición de “las partes”, es decir, identificar formalmente a las entidades físicas (personas) o morales (organizaciones) entre las cuales se celebra el contrato.
  • Procedimientos: Las funciones son principalmente lo que hace que un programa, haga tic tac y estas deben ser cuidadosamente estructuradas y ser particularmente escritas de manera clara y precisa con el fin de lograr los resultados previstos. También algunas funciones realizan llamadas (o hacen referencias) a otras funciones. Escribir las cláusulas de los contratos son el equivalente a programar las funciones en un programa.
  • Sintaxis y gramática: Cada uno de los lenguajes de programación tiene una sintaxis específica que define las estructuras utilizables (tipos de datos, clases, procedimientos, estructuras de datos, palabras reservadas, y la forma de redacción, puntuación, etc.). Como usted ya debe imaginarse, esto es comparable a las características del idioma en que un contrato está escrito; sin embargo, vale la pena mencionar que, al igual que con cualquier lenguaje de programación, el no conocer un grado decente del lenguaje y sus reglas, puede echar a la basura el resultado esperado del contrato, por ejemplo al cambiar de lugar una coma, u olvidar la declaración o inicialización (descripción) de un término, etc,.

Así como es recomendable utilizar números de línea al revisar los archivos de código fuente, también es sumamente recomendable utilizar números de cláusulas para facilitar la lectura de los contratos.

Adicionalmente un archivo de código fuente se encuentra suscrito a ubicación dentro del sistema de archivos (llámese directorio, folder o carpeta), y se le asigna una fecha de creación y el número de bytes de los que consta; del mismo modo los contratos se deben adscribir a una ubicación (localidad), deben tener una fecha de creación (y de vigencia) y un número de páginas (el cual es recomendable agregar en cada una de ellas).

En ocasiones, los archivos de código fuente especifican directivas que para su interpretación por un compilador específico. De la misma manera, algunos contratos adscriben la jurisdicción del mismo para su interpretación por ciertas autoridades específicas en una localidad o de cierta índole. Dicha situación es importante tomarla en cuenta porque (al igual que si no contamos con el compilador específico) esto puede resultar en una interpretación distinta del contenido del documento y la incursión de gastos importantes para las partes.

Por último, los certificados de programa son comparables a las firmas del contrato ya que dan cuenta de su legitimidad y validan su contenido.

Si están los contratos o el software están bien escritos, por lo general son  simples, elegantes, robustos y escalables. A este tipo de documentos se les llama con frecuencia “obras maestras”, como si fueran poemas dentro de  sus dominios respectivos.

Por desgracia para nosotros los desarrolladores no existen IDEs (fuera de los procesadores de palabras) ni compiladores que nos ayuden a escribir o revisar contratos, pero espero que este breve texto pueda servir a mis compañeros “codificadores” a por lo menos identificar las piezas faltantes y los errores comunes en estos documentos tan necesarios en nuestro quehacer profesional.

“Codificar o no codificar, es el dilema diario y permanente de los programadores…”