Cómo Analizar Datos

El análisis de datos es un proceso en las primeras etapas del desarrollo de software, cuando examinas una actividad de negocio y encuentras los requerimientos para convertirlo en una aplicación de software. Esta es una definición formal, la cual puede
conducir a pensar el análisis de datos es una acción que deberías dejar mejor a los analistas de sistemas, mientras tú, el programador, deberías enfocarte en codificar lo que alguien más ha diseñado. Si seguimos estrictamente el paradigma de la
ingeniería de software, ello podría ser correcto. Los programadores experimentados se vuelven diseñadores y los más agudos diseñadores se convierten en analistas de negocios, siendo así intitulados a pensar en todos los requerimientos de datos y a
darte tareas bien definidas para hacer. Esto no es completamente exacto, debido a que los datos son el núcleo de cada actividad de la programación. Lo que sea que hagas en tus programas, estás moviéndote alrededor de o modificando los datos. El
analista de negocios está analizando las necesidades a una mayor escala, y el diseñador de software está exprimiendo más dicha escala de tal forma que, cuando el problema aterriza en tu escritorio, parece que todo lo que necesitas hacer es aplicar algoritmos inteligentes y comenzar a mover los datos existentes.

No es así.

No importa en cuál etapa empieces a verlo, los datos son el principal interés de una aplicación bien diseñada. Si miras de cerca cómo un analista de negocios obtiene los requerimientos de la solicitud del cliente, te darás cuenta de que los datos juegan un
papel fundamental. El analista crea los llamados Diagramas de Flujo de Datos, donde todos las fuentes de datos están identificadas y el flujo de la información es modelada. Habiendo definido claramente cuáles datos deberían formar parte del
sistema, el diseñador modela las fuentes de datos, en términos de relaciones de bases de datos, protocolos de intercambio de datos, y formatos de archivos, de tal manera que la tarea está lista para ser pasada al programador. Sin embargo, el proceso no
termina todavía, porque tú "el programador" aún después de este completo proceso de refinamiento de datos, se te pide analizar los datos para llevar a cabo la tarea de la mejor forma posible. La línea final de tu tarea es el mensaje central de Niklaus
Wirth, el padre de varios lenguajes. "Algoritmos + Estructuras de Datos = Programas" Nunca ha habido un algoritmo que permanezca solo, haciendo algo para él mismo.

Cada algoritmo está supuesto a hacer algo para al menos una pieza de datos.

Por lo tanto, puesto que los algoritmos no atan sus ruedas al vacío, necesitas analizar tanto los datos que alguien más ha identificado para ti como los datos que son necesarios para escribir tu código. Un ejemplo trivial hará la cuestión más clara. Estás implementando una rutina de búsqueda para una biblioteca. De acuerdo a tus especificaciones, el usuario puede seleccionar libros mediante la combinación de género, autor, título, editor, año de impresión, y número de páginas. La meta última de tu rutina es producir una sentencia SQL legal para buscar la base de datos subyacente.

Basado en esos requerimientos, tienes varias opciones: chequear cada control por turnos, usar una sentencia "switch", o varios "ifs"; hacer un arreglo de controles de datos, chequear cada elemento para ver si está establecido; crear (o usar) un objeto de control abstracto desde el cual heredar todos tus controles específicos, y conectarlos a un motor conducido por eventos. Si tus requerimientos incluyen también optimizar el desempeño de la consulta, asegurándote que los ítems sean Chequeados en un orden específico, puedes considerar el uso de un árbol de componentes para construir tu sentencia SQL.

Como puedes ver, la elección del algoritmo depende de los datos que decidas usar, o crear. Tales decisiones pueden hacer toda la diferencia entre un algoritmo eficiente y uno desastroso. Sin embargo, la eficiencia no es la única preocupación. Puedes usar una docena de variables en tu código y hacerlo tan eficiente como podría serlo. Pero tal pieza de código podría no ser fácilmente mantenible. Quizá el elegir un contenedor apropiado para tus variables podría mantener la misma velocidad y adicionalmente permitir a tus colegas comprender mejor el código cuando lo vean el próximo año. Además, el escoger una estructura de datos bien definida puede permitirles extender la funcionalidad de tu código sin reescribirlo.

A la larga, tus escogencias de datos determinan qué tanto sobrevivirá tu código después de que lo finalices. Permíteme darte otro ejemplo, solamente algo más en lo que pensar. Supongamos que tu tarea es encontrar todas las palabras en un diccionario con más de tres anagramas, donde un anagrama debe ser otra palabra del mismo diccionario. Si piensas en ello como una tarea computacional, terminarás con un esfuerzo sin fin, intentando trabajar todas las combinaciones de cada palabra y luego comparándola a las otras de la lista.

Sin embargo, si analizas los datos a mano, te darás cuenta de que cada palabra puede ser representada por un registro conteniendo la palabra en él mismo y un arreglo ordenado de sus letras como ID. Armado con tal conocimiento, encontrar anagramas significa tan solo ordenar la lista sobre el campo adicional y seleccionar las que comparten el mismo ID. El algoritmo de fuerza bruta puede tomar varios días para ejecutarse, mientras que el inteligente solo es cuestión de unos pocos segundos.

Recuerda este ejemplo la próxima vez que estés encarando un problema intratable.

Fuente:

Cómo Ser Un Programador: Un Resumen
Corto, Comprensivo y Personal
por Robert L. Read

Si quieres conocer otros artículos parecidos a Cómo Analizar Datos puedes visitar la categoría SISTEMAS OPERATIVOS.