A mi amigo José Ramón le escuche una frase (que seguramente la escuchó en algún lado) que me dejo gratamente impresionado y la aplico con mucha frecuencia... mas de la que me gustaría.
Una visión sin ejecución, es un sueño..... pero una Ejecución sin visión, es una pesadillaEsto pasa TODOS los dias en el área de informática sobre todo, cuando ponemos al frente de un proyecto importante a personas que no tienen la experiencia necesaria para llevarlo a cabo.
Si por antiguedad, o porque "ya le toca", ponemos al frente de un proyecto importante, a un buen programador, con muchos años de experiencia, pero que lo unico que sabe hacer es programar, lo mas seguro es que el proyecto vaya directamente al fracaso en el peor de los casos, y en el mejor, a una demora considerable en el tiempo de realización.
Y no tengo nada contra los programadores experimentados, al contrario, he aprendido muchisimas cosas de ellos, sin embargo hay que conscientes que un
buen programador, no necesariamente es un
buen analista, por eso hay niveles... hay analistas, hay programadores y hay analistas-programadores.
¿ Qué se espera de un buen analista ?, bueno, por lo menos que conozca
la teoría de lo que es el diseño de sistemas, y eso no se aprende en ningún libro, ni leyendo ningún manual de Clipper, SQL o Windows, algunas universidades dedican 2 o mas semestres al estudio de estas materias, porque no es cosa fácil hacer un diseño exitoso de un sistema.
El problema es que a nivel microcomputación, la carencia de tiempo para hacer las cosas, demanda que se atienda primerlo lo urgente y que lo importante se deje para después, o que se nos olvide totalmente, así hemos estado acostumbrados a trabajar y el modelito nos ha funcionado... total ¿ para qué cambiarlos ? si así hemos trabajado hasta ahora y hemos salido adelante.....
Ese es el error mas común de todo el microinformatico, que no pensamos a futuro y cuando nos llegan los grandes proyectos, no sabemos como enfrentarlos, porque simplemente realizamos
ejecución sin visión.Esto quiere decir, que nos ponemos a tirar líneas de código como tontos, dejando de lado la parte mas importante del sistema que es ....
EL OBJETIVO y cuando vienen los cambios comienza el sufrimiento porque no previmos que los requerimientos podian cambiar.
Plantear el objetivo puede parecer simplista, pero no, el objetivo no es simplemente "
voy a hacer un sistema de facturacion que trabaje en entorno cliente/servidor con SQL y usando un servidor Linux", decir que este es nuestro objetivo, es una gran tonteria, ¿ porqué ?, pues porque verlo asi de simple es arrancar de
ningún lado, para intentar ir
a ninguna parte.
Hay muchas cosas que analizar en tan aparentemente simple objetivo. Veamos:
Vamos a relizar un sistema de facturación, bien, asumo que conozco
las reglas de negocio que intervienen en una facturación, como el control de clientes, proveedores, inventarios, punto de venta, etc.
En entorno cliente/servidor, quiere decir que por lo menos conozco la arquitecutra C/S y sus ventajas contra la Arquitectura Distribuida, conozco conceptos como Rollback, transacción, seguridad, DBA, arquitectura de 3 capas, etc, los manejo con soltura y estoy dispuesto a aplicarlos.
Con SQL, lo que quiere decir, que UNA de mis herramientas va a ser este lenguaje de programación, ojo: SQL es un lenguaje de programación, no es una base de datos, ni un producto ni nada por el estilo, es simple y llanamente un vil lenguaje de programación, solo una herramienta mas del desarrollo de nuestro sistema
A partir de este conocimiento básico de lo que queremos hacer, debemos proceder con la parte mas básica de un sistema diseñado sobre arquitectura de 3 capas, que es el modelo sobre el cual se deben construir las aplicaciones Cliente / Servidor.
El primer nivel, el básico y el primero que debemos comenzar a construir, es la capa de
BASE DE DATOS, es decir, el diseño de nuestro esquema de almacenamiento, este proceso requiere de mucha mas habilidad que simplemente conocer el lenguaje SQL (el SQL entra en la segunda capa del modelo, la de negocios). Para realizar un analisis exitoso y triunfador (como dice mi amigo AGG), es necesario conocer conceptos como Analisis Top-down, diagramas entidad-relación, formas normales, diagramas CRUD, la aplicación de todas estos conceptos al diseño de la base de datos (Base de datos = coleccion de tablas) nos garantiza que los siguientes pasos van construidos sobre cimientos solidos y que el proyecto no se nos vaya a venir abajo a la mitad.
SAP es el sistema ERP de mayor uso en el mundo ¿ por qué ? porque sus ingenieros se llevaron 2 años SOLO EN EL ANALISIS DE LA BASE DE DATOS, pero un buen analisis de la bd los consagro en el gigante del software que son hoy.
Un buen analisis de una base de datos, implica precisamente no casarse con ninguna marca en especial o con algún producto, nuestra base de datos debe de ejecutarse perfectamente en MySQL, Informix, Sybase, SQL Server sin alterar el diseño orignal de la misma, o bien con muy pocos cambios, a fin de cuentas el objetivo es utilizar el Cliente/Servidor, sin especificar ninguna marca de SGBDR en especial, esto no significa que tengamos que tener un servidor por cada base de datos a probar... ¡ por su puesto que no !, eso es precisamente lo que tratamos de evitar, nuestro modelo debe estar tan bien analizado, que se pueda ejecutar sobre cualquier plataforma.
Una vez que tengamos bien analizada nuestra base de datos, el objetivo esta cumplido a la mitad, ya no partimos de
ningún lado puesto que ya tenemos un punto de partida bien analizado y establecido: nuestra base de datos.
Bien, ahora hacia donde vamos.... ¿ seguimos el camino a
ninguna parte ?, por su puesto que no, nuestro objetivo ahora es claro, vamos a trabajar CON CUALQUIER BASE DE DATOS, esto evita que a mitad del proyecto venga algún otro programador brillante con nuevas ideas o casado con alguna marca a vendernos la moto de que tenemos que ir a donde el dice... porque claro, el que no sabe a donde va, cualquier camino le parece bueno, pero no en nuestro caso, nosotros ya sabemos a donde queremos llegar, y estamos decididos a no casarnos con ningun producto en especifico.
Vamos ahora a la segunda capa, la
Capa de Negocios en esta capa se establecen las operaciones que van a hacer uso de nuestras bases de datos, es decir,
las reglas de negocio, lo que conocemos a nivel programación como
Queries, es decir, las instrucciones SQL que van a realizar la explotacion de nuestra base de datos, debemos siempre de tratar que nuestras instrucciones sean lo mas estandarizadas posibles al estandar SQL, y evitar en lo posible utilizar extensiones propias de algun SGBDR en particular. Si programas en Windows, la interfaz ADODB te soluciona una buena cantidad de esos problemas y nuevamente aquí tenemos que evitar casarnos con cualquier plataforma o sistema operativo.
Y finalmente, pero no por eso menos importante, la capa de interfaz, esta es la capa que le da la cara al usuario, que puede ser que se trate de un programa en Windows, una aplicacion en modo terminal, o un programa PHP o CGI corriendo sobre WEB.
La importancia de entender esto y muy poca gente lo hace, radica en que cada capa es independiente de las otras, lo que garantiza que nuestro sistema sea suficientemente versátil para soportar cualquier cambio que se haga en el diseño sobre la marcha.
Entender estos conceptos es basico para realizar un proyecto chico, mediano o grande de manera exitosa y nos capacita para responder mejor a los cambios que vayan surgiendo durante el desarrollo del proyecto.
A nivel software "en caja" tenemos que ser lo mas genericos posibles, porque no sabemos con que equipo cuente el usuario final, algunos productos como los de ASPEL en México, ahora trabajan la multiplataforma de la base de datos para que se puedan montar sobre el servidor de base de datos que se requiera, los manuales proveen de un buen diccionario de datos perfectamente documentado que permite montar productos como SAE sobre cualquier servidor de base de datos relacional..... eso si fue una
"visión con ejecución".
