• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Hace unos meses tuve una conversación muy interesante con un amigo, gran experto en arte y que anda metido desde hace años en temas de arte digital. Claro, a él, la programación le interesa principalmente como modo de expresión, y me estuvo contando iniciativas y cosas que hace la gente para experimentar… por ejemplo, la programación de virus como arte digital, o como experimentos de vida digital.

Este tipo de conversaciones son siempre interesantes, porque te ayudan a ver tu profesión con un poco de perspectiva, y creo que también te permiten descubrir por qué haces alguna de las cosas que haces. Me explico:

Interesándose por el tipo de empresa que somos, le explicaba que nuestra forma de ver Ender no ha sido nunca la de una empresa grande…nosotros nunca hemos tenido el objetivo de convertirnos en una gran consultora, sino más bien nos hemos visto siempre como un taller de software; nos encontramos más cerca de un despacho de arquitectura que de Microsoft o de SAP.

Nos preocupa más la mejora de nuestros procesos de desarrollo, la selección de las mejores tecnologías y el ser expertos en nuestro trabajo que utilizar las tecnologías más populares o crecer en facturación de forma rápida. Por eso creo que somos un negocio, no una empresa, para nosotros son más importantes las cosas que hacemos que el dinero que ganamos.

La visión de mi amigo de la programación (o la parte de la programación que le interesa, mejor dicho) se basa en la capacidad de experimentar y expresar, de utilizar el software como un lenguaje que te ayude a explicar lo que sientes o cómo ves el mundo; es decir, la programación como arte. Desde este punto de vista, el dinero no tiene importancia… no haces las cosas para ganar dinero, sino porque lo necesitas como medio de expresión.

El punto de vista empresarial es exactamente el contrario. No te interesa especialmente lo que haces, y tu preocupación por mejorar los procesos tiene como objetivo ser más productivo y generar más negocio. Es el punto de vista de las grandes consultoras, en las que el fin justifica en mayor o menor medida los medios que se utilizan… No importa la tecnología salvo desde el punto de vista de la productividad o de lo que el cliente considere ‘lo mejor’. Esto es lo que hace que los programadores de grandes empresas trabajen una gran cantidad de horas al día, y que a veces  la calidad de los desarrollos sea algo cuestionable.

En Ender buscamos un punto de vista intermedio… sabemos que tenemos que ganar dinero para vivir, y nos encantaría hacernos ricos, como a todos (creemos que, como lo que hacemos lo hacemos bien, en algún momento llegaremos). Sin embargo, nos preocupa más hacer bien el trabajo, o más bien estar satisfechos con el trabajo que hacemos, que el importe del proyecto en el que trabajamos.

A esta situación intermedia, en la que no renunciamos al interés económico, pero poniendo por delante  el trabajo que hacemos, lo llamo artesanía. No es la definición ortodoxa, ya que no hacemos las cosas con las manos ni somos un oficio tradicional, pero a falta de una palabra mejor, es la que utilizamos… no hacemos software por amor al arte ni por el amor al dinero: hacemos software por el amor al software.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

En mi último artículo hacía una introducción al proceso de modelado de una base de datos relacional, utilizando como ejemplo el proceso de matriculación de un centro de enseñanza. Siguiendo con esa línea, en este artículo voy a describir cómo hacemos el modelo de datos en Bravo, uno de nuestros sistemas, en este caso uno especializado en centros de enseñanzas de idiomas. Para una introducción más teórica, podéis echar un vistazo al artículo de la wikipedia.

Caso de uso

Como en el artículo anterior, lo primero es hacer la descripción de un caso de uso que nos meta en materia, y nos ayude a entender cuál es la funcionalidad que tenemos que proporcionar (o, en este caso, una descripción de los procesos que tenemos que modelizar). Bueno, en realidad la descripción que hago es más parecida a una historia de usuario de eXtreme Programming que al caso de uso típico de UML, pero nos entendemos…

Si en el artículo anterior el actor principial del caso de uso es un alumno que acude a la escuela, en este caso es el responsable formativo o Director of studies (aquí hay una buena descripción del puesto). Es la persona, en un centro de formación, encargada de la elaboración de los horarios, la gestión de las incidencias (que ahora veremos) y la asignación de profesores y aulas a los grupos que se formen.

Su necesidad es la de tener controlados todos los horarios del centro de formación. Es decir, tiene que poder saber dónde está cada profesor en todo momento, qué clases no se han impartido y por qué y saber qué profesores hay disponibles y qué aulas están libres en un momento determinado.

También necesita saber cuántas horas ha trabajado cada profesor en un mes y cuántas horas un profesor tenía que haber trabajado, y el motivo de las cancelaciones.

Así, el director de estudios (DOS, de aquí en adelante) recibe la petición de formar un grupo nuevo para uno de los cursos definidos en el ejemplo anterior, porque se han matriculado muchos alumnos y no hay plazas suficientes. El DOS entonces primero decide el horario que tendrá el grupo. En el caso de este ejemplo, el curso para el que hay que crear el grupo define 3 horas por semana (es lo que se llama un curso extensivo), que se impartirán Lunes, Miércoles y Viernes de 19:00 a 20:00. Con esta información definida, el DOS necesita buscar un profesor que esté disponible en ese horario, y un aula que también lo esté. Una vez localizada toda la información necesaria para montar el horario, hay dejar anotado el nombre de los alumnos que asistirán a este grupo.

Con toda esta información definida, el grupo puede empezar. Normalmente, se le proporciona al profesor a principio de mes una hoja de asistencia, que es un informe en el que se detallan el horario de cada grupo con sus alumnos, para que el profesor pueda hacer un seguimiento de la asistencia de los alumnos y de las incidencias que puedan aparecer.

Una vez el grupo ha comenzado, y los alumnos están asistiendo a clase, al director de estudios se le pueden presentar varias situaciones que tiene que manejar:

1. El grupo cambia de profesor, de horario o de aula. Quizá porque el profesor se vaya de la empresa o por la razón que sea, de vez en cuando hay que cambiar el profesor de un grupo. Sin embargo, a la hora de aplicar este cambio es importante tener en cuenta que debemos mantener la información histórica. Es decir, cuando haya un cambio de horario debemos saber qué profesor había antes y cuál hay ahora, y cuándo se produjo el cambio. Para el cálculo de total de horas trabajadas, es imprescindible.
2. Entran alumnos nuevos, u otros dejan el grupo, cuando los alumnos se dan de alta y se incorporan al grupo, o quizá cuando un alumno cambia de grupo porque el horario le viene mejor. Como en el caso anterior, tendríamos que saber por qué grupos ha pasado el alumnos y cuándo se ha incorporado a cada grupo.
3. Una clase no se imparte, por ejemplo porque el profesor se ha puesto enfermo y no se ha encontrado sustituto a tiempo, o porque el centro estaba cerrado. En este caso, tenemos que saberlo, porque el nº de horas trabajadas por el profesor tendrá que cambiar, y hay algunos casos (cuando se ha contratado un nº de horas de formación concreto) en los que esa clase debe recuperarse en otro momento, ya sea otro día de la semana o quizá alargando la duración del grupo un poco.
4. Un profesor sustituye a otro. Es el caso en el que un profesor se pone enfermo, o se ha cogido un día libre, y otro profesor le sustituye. En este caso tenemos que saber quién tenía que dar la clase (ha impartido una hora menos) y quién ha dado la clase en realidad (hay impartido una hora más).
5. Un grupo se cierra. Se dan de baja todos los alumnos o (lo que es más común), se dan de baja tantos alumnos que no compensa mantener el grupo abierto, así que se reúnen dos grupos con pocos alumnos y se crea un grupo con un nº de alumnos más acorde con las necesidades tanto del centro como de los propios alumnos.

Descripción de las entidades

Después de la descripción del proceso, detallo las entidades (tablas) que utilizamos para m0delizarlo:

• Cursos: podéis ver la descripción en el artículo anterior.
• Profesores: el personal que imparte las clases.
• Grupos: La oferta de horarios y días entre los que los alumnos pueden elegir para asistir a clase, dentro de cada curso.
• Horarios: Dentro de cada grupo, tenemos que almacenar su horario (que puede tener una estructura compleja, por ejemplo: Lunes y Miércoles de 19:00 a 20:00 y Viernes de 13:00 a 14:00, es más común de lo que parece). Además, hay que almacenar el historial de horarios por los que ha pasado el grupo, incluyendo los profesores.
• Clases: Cada uno de los días de clase dentro del horario del grupo. Por ejemplo, si tenemos un horario Lunes de 19:00 a 20:00, entre el 1 y el 30 de Abril, tendrá que haber un registro para cada Lunes entre esas dos fechas, para que después podamos gestionar si las clases se han impartido o no, cada una por separado.
• Tipos de tarea: Hay situaciones en las que es conveniente diferenciar qué se hace en los horarios del grupo. Podemos tener grupos de formación, como los que se describen en todo el artículo, pero también podemos tener grupos que gestionen las tareas administrativas de los profesores (preparación de clases, etc.) o incluso la agenda del personal no docente, simplemente diferenciando por tipo de tarea.
• Tipos de cancelación: Necesitamos saber cuando una clase no se imparte, así que nos hará falta una gestión de motivos de cancelación, y por tanto una entidad que los defina.
• Alumnos: ya la vimos en el artículo anterior.
• Alumnos en grupos: Tenemos que almacenar la información de qué alumnos están apuntados a qué grupos y, además, nos hace falta saber, según el caso de uso, cuándo entró y cuándo salió cada alumno de su grupo.
• Asistencia: Para cada una de las clases, tenemos que saber qué alumnos estaban apuntados a ella, y para cada uno de ellos, si asistió a clase o no.

Gráficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas… algunas líneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es ‘hija’ de otra, con la punta de flecha apuntando al padre.

Como podéis ver, sólo están indicados los campos que forman el modelo de datos… las claves primarias y las claves ajenas, que en cualquier caso deben estar ocultas al usuario final. En la siguiente sección describiremos los campos de cada tabla.

Campos

Como siempre, sólo pongo los campos que considero más relevantes para la descripción del modelo de datos, y no repito los campos de clave ajena para las relaciones, que ya están descritos en el gráfico. La definición de cursos y grupos es la misma que en la que hay en el artículo de matriculación:

Cursos

• nombre: varchar(100)
• descripcion: Memo. Se utilizará, en el contrato que se imprime para el cliente, para hacer una descripción larga del curso en el que el alumno se está matriculando. En uno de los sistemas que tenemos, en lugar de tener un campo memo, tenemos una tabla separada en la que se guardan, por tipologías, distintos campos memo, que se imprimen en distintos lugares del contrato.
• fecha_inicio: date
• fecha_fin: date

Profesores

• nombre, primer_apellido, segundo_apellido: varchar(100)
• nombre_completo: es una costumbre crear un campo calculado que almacene el nombre completo del profesor. Así, las búsquedas se hacen sobre este campo y es más fácil encontrar al profesor en cuestión.
• dirección: Memo
• telefono, telefono_movil: varchar(50). No os quedéis cortos con el tamaño de los campos, más vale pasarse que dejarlo con 9 dígitos y descubrir que tienes que poner el +34 delante para poder mandar SMS después.
• NIF_NIE, Pasaporte: en campos separados

Grupos

• nombre: varchar(100)
• codigo: varchar(20). Siempre viene bien tener una codificación además del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el código del grupo en la Fundación Tripartita.
• fecha_inicio: date
• fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y además estas fechas no pueden estar fuera de las fechas del curso al que pertenecen.
• lugar: varchar(100) de impartición del grupo. En general, hacemos una gestión de aulas, pero eso lo ampliaré en otro artículo.
• notas: memo, del grupo
• horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por debajo de esta, pero no voy a entrar en tanto nivel de detalle ahora.
• maximo_alumnos: Integer. Máximo número de alumnos permitidos en el grupo.
• numero_alumnos: Integer. Es el número de alumnos existentes en el grupo. Este campo es de sólo lectura para el usuario, y es calculado, a través de una serie de Triggers en la base de datos, para poder saber rápidamente el número de alumnos activos en cada grupo sin tener que estar sumando.

Horarios

• fecha_inicio, fechafin : date. Por defecto, serán las del grupo con el que estamos trabajando, pero si cambiamos de horario a mitad del grupo, habrá que cerrar el horario anterior (cambiar fecha_fin) y crear un horario nuevo.
• L,M,X,J,V: Boolean. Aquí hay dos formas de hacerlo… puedes poner campos booleanos para cada día de la semana, y si el horario tiene L = sí y X = sí, entonces el horario es Lunes y Miércoles, o poner un campo “día” de tipo entero y tener un registro de horario para cada día de la semana. Me inclino por la primera solución, que hemos utilizado en nuestro sistema Atenea que por la segunda, que es la que utilizamos en Bravo. Los días de la semana no son algo que vaya a cambiar, y el interface y la forma de mostrar el horario es más fácil de implementar y más intuitivo para el usuario cuando usas una sóla fila que cuando tienes 3 para el mismo horario.
• hora_inicio, hora_fin: Time
• id_profesor: por defecto, es el profesor definido como profesor del grupo, pero podemos tener la situación en la que haya dos profesores en el mismo grupo (como pasa muy a menudo con los seminarios y los cursos intensivos).
• id_tipo_tarea: Integer. Es el tipo de tarea por defecto que tendrán todas las clases del horario. También existe la posibilidad de poner un tipo de cancelación por defecto, como hemos hecho en Atenea. Lo vemos más abajo, en las clases.

Clases

• fecha: Date. A estas alturas, ya no tenemos fecha de inicio y fecha de fin… esto es ya cada uno de los días de clase individuales, y por tanto lo que hay es una fecha
• hora_inicio, hora_fin: Time. Por defecto serán las del horario al que pertenece la clase. Están también en la tabla de clases porque eso te permite gestionar excepciones, del tipo que la clase de hoy dura media hora más para recuperar parte de una clase anterior que se canceló, cosas así.
• id_tipo_tarea: el tipo de tarea del horario, por defecto. Igual que antes, está replicado en esta tabla para permitir excepciones.
• id_tipo_cancelacion: Tenemos dos formas de proceder… podemos definir un tipo de cancelación por defecto, que será el que tengan todas las clases (nosotros utilizamos “clase impartida”, para indicar que no ha habido cancelación), o también podemos poner el tipo de cancelación en el horario, de forma que todas las clases de ese horario tendrán ese tipo de cancelación y luego nosotros cambiamos el tipo de cancelación para las clases que no se imparten.
• Notas pedagógicas: Memo. Suele ser buena idea poner un campo de notas pedagógicas que, el profesor, al rellenar la asistencia (lo vemos más abajo) puede completar. Esto hace que, cuando un profesor tiene que hacerse cargo de un grupo que ya ha empezado, puede leer las notas que dejó el otro profesor (lo que se llama el Class Record) y saber por dónde van y qué es lo siguiente que hay que hacer.

Tipos de Tarea

• nombre: varchar(100)
• lectiva, transporte, administrativa : boolean. Con estos campos podemos sumar después fácilmente las horas según los tipos de tarea. Por ejemplo, podemos tener un tipo de tarea “Horas lectivas” y otra “Horas lectivas en Sábado”, que se pagan de distinta forma y queremos tener controladas, pero sin embargo todas son horas lectivas, y a la hora calcular totales de horas, las queremos agrupadas.

Tipos de cancelación

• Nombre : varchar(100)
• clase_impartida: boolean. Así podemos tener distintos tipos de cancelación que indican que la clase no se ha impartido, y luego sumar todas juntas para saber cuántas horas se han impartido y cuántas no.
• implica_pago_profesor: Según el tipo de cancelación y el convenio, hay tipos de cancelación que, aunque no cuenten como clase impartida, sí que se van a pagar al profesor.
• implica_cobo_cliente: En el caso de los grupos para empresa o en los individuales, normalmente se factura por horas (lo veremos en el artículo sobre facturación), y en estos casos se da la circunstancia de que las cancelaciones no son sólo por parte del profesor o del centro de formación: en estos casos, es posible (de hecho, es lo más común) que sea el cliente el que cancele la clase. Normalmente, se definen en este caso dos tipos de cancelación: Cancelación en plazo, que es cuando el cliente ha avisado de que no va a darse la clase, y entonces no se le factura, o Cancelación fuera de plazo, que es el caso tan típico en el que el profesor se presenta y no hay nadie a quién darle clase. En este caso, normalmente, la clase se factura aunque no haya sido impartida, pero es importante para el DOS saber qué clases han sido canceladas de esta manera. A final de curso, cuando se evalúa el avance del alumno, es importante tener en cuenta a cuántas clases el alumno ha acudido realmente, no cuántas se le ha facturado al cliente.

Alumnos

• nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en clientes es sólo nombre por si
• primer_apellido: varchar(100)
• segundo_apellido: varchar(100)
• nombre_completo: varchar(300):
• etc. de datos personales (profesión, teléfonos, email, etc.)

Alumnos en grupos

• fecha_inicio: date
• fecha_fin: date. Suele ser una intersección entre la duración del grupo y la de la matrícula, pero cuando el alumno cambia de grupo, para una matrícula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta también la posibilidad de que en un mismo curso, pagando más, un alumno pueda asistir a varios grupos (esto también lo he visto).

Asistencia

• asiste: boolean. Normalmente, cuando se crean los registros de asistencia (que se crean automáticamente cuando se crean las clases), el campo asiste está inicializado a NULL, para que así sepamos que esta información todavía no está disponible. Será el profesor cuando introduzca la asistencia el que indique si el alumno asiste o no. Mientras tanto… no se sabe.
• falta_justificada: boolean. Todo el proceso que está definido en este artículo se basa en la idea de que la asistencia de los alumnos y la cancelación de una clase son cosas separadas, porque la gestionan personas separadas. La información de cancelación de clases implica que se indique el motivo de dicha cancelación, y dicha información va a afecta a la facturación al cliente y al pago a los profesores, y por tanto es responsabilidad del DOS. La información de asistencia de los alumnos tiene valor desde el punto de vista académico (para calcular los porcentajes de asistencia de los alumnos a la hora de evaluar el rendimiento) y se usa en conjunción con la información de calificaciones. Como actualizar esta información es muy trabajoso por el volumen de datos que representa, los sistemas en general están pensados para que sean los profesores los que introduzcan esta información. Como la información de cancelaciones puede afectar directamente a sus pagos, los profesores no la introducen directamente en el sistema. Por tanto, que todos los alumnos tengan asiste = NO no implica que la clase esté cancelada… es lo tendrá que introducir el DOS, incluyendo el motivo.

Triggers y procedimientos almacenados

Este proceso, como hemos visto por la definición de las tablas, tiene muchos procesos ‘automáticos’, propios de la base de datos. Principalmente:

• Al crear un horario, tiene que haber un trigger que inserte en la base de datos todas las clases de ese horario, teniendo en cuenta la fecha de inicio y de fin y los días de clase, e incluyendo la gestión de días no lectivos si la hemos hecho.
• De la misma forma, necesitamos un trigger que al crear clases o incluir alumnos en grupos inserte en la base de datos los registros de asistencia de los alumnos y las clases a los que pertenecen.

Es muy importante que estos dos procesos estén incluidos en la base de datos… El trabajo principal de los DOS, y la fuente principal de información de producción en la empresa es esta parte, y por tanto es muy importante que estos procesos sean ágiles. En las primeras versiones de Bravo, este proceso sea hacía en el lado cliente del sistema, y el rendimiento dejaba muchísimo que desear.

Consideraciones finales

Creo que más o menos es todo… es muy importante que seamos conscientes de que esta gestión de horarios es muy detallada, y que por tanto implica mucha gestión para mantenerla al día: además de dar de alta los grupos, hay que mantener los cambios de profesor y ser muy preciso con las fechas de modificación, hay que introducir las cancelaciones, la asistencia de los alumnos… implica muchas horas de trabajo mantenerlo al día. A la hora de hacer una implementación como esta, hay que valorar los beneficios que reporta. Al principio del artículo he hablado que este modelo está pensado para centros de enseñanza de idiomas, lo cual no es del todo exacto. Este modelo está pensado para organizaciones que necesitan saber el número exacto de horas que se han trabajado en un periodo de tiempo dado, ya sea para facturar al cliente (como ocurre en los centros de idioma, en los departamentos de enseñanza para empresas) como para pagar al personal.

No he hablado de la gestión de los contratos de los profesores, o del proceso de facturación mismo, que incluiré en otros artículos, ni he descrito la manera de obtener informes de totales de horas (que se basa simplemente en sumar la duración de las clases en base a los criterios de fechas, tipos de cancelación, tareas, profesores, etc. que se necesiten).

Intentaré, en mi siguiente artículo, hacer un descripción de un proceso de facturación en el que se tengan que cobrar horas, y de cómo dejarlo lo suficientemente abierto como para facturar cualquier otra cosa.

Saludos a todos,

d

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

En el desarrollo de software para empresas, el almacenamiento de la información de un modo organizado es fundamental… la mayoría de los casos en los que el programador contesta “no se puede hacer” a un requerimiento de un cliente se debe a un error en el modelado de la base de datos que funciona como soporte a la aplicación. En este artículo voy a intentar explicar, con un ejemplo práctico, un buen modelado de datos.

Como, de alguna forma, estamos especializados en el software de gestión de empresas de enseñanza, voy a utilizar un ejemplo de uno de esos modelos: la gestión de matriculación de los alumnos, incluyendo los recibos que tienen que pagar, y el pago parcial de los mismos. Voy a explicar en este artículo el funcionamiento del proceso (para que podamos hacer el seguimiento de la implementación), las tablas que utilizamos y los campos (de forma resumida) que componen cada una de las tablas. De paso, daré una idea de los índices, procedimientos almacenados y triggers que nos pueden resultar útiles para que el rendimiento de la base de datos sea bueno.

Descripción del proceso de matriculación (el caso de uso)

Vamos a imaginarnos que nos encontramos en una academia de idiomas, en la que los alumnos se matriculan y asisten a clase de forma temporal. En este caso me voy a centrar en lo que se llaman “grupos abiertos”, es decir, grupos en los que cualquiera se puede matricular (en oposición a los grupos de empresa o grupos cerrados, que suelen funcionar de forma diferente).

Cuando llegamos a la academia, se nos ofrece un folleto o catálogo de productos y servicios, en el que se detallan los diferentes cursos en los que nos podemos matricular, y las diferentes formas de pago que podemos utilizar. Seleccionamos uno de los cursos, la forma de pago que más nos conviene, el horario al que vamos a asistir, y con esta información nos matriculamos. Como forma de pago, en este caso, vamos a utilizar un pago mensual, y queremos que se nos domicilie el pago a través de nuestra cuenta bancaria.

En la academia, llegado este punto, introducen en su sistema de información nuestros datos y nos imprimen el contrato de prestación de servicios, en el que se incluyen todos nuestros datos, el curso en el que nos hemos matriculado y todos los pagos que vamos a tener que realizar mientras estemos matriculados. Nos piden, de paso, que paguemos una reserva de plaza, que es una pequeña cantidad del primer recibo.

En el siguiente día de clase, nos presentamos, y el profesor comprueba en su hoja de asistencia que estamos incluidos en el grupo… nos da la bienvenida, y empezamos a estudiar.

El modelo de datos

A partir de aquí haré una descripción de la estructura de tablas y columnas para almacenar la información de este proceso. Primero, algunas generalidades sobre cómo crear los campos.

Generalidades

Hay algunas cosas básicas a la hora de modelizar el modelo de datos que usamos como convenciones (nomenclatura, cosas así). Por ejemplo:

1. La clave primaria de las tablas siempre es un identificador autoincremental. Todas las tablas tienen así un identificador interno, mantenido por el sistema. Así, las claves ajenas son más fáciles de mantener.
2. En general, nosotros no solemos poner campos requeridos… preferimos hacer la gestión dentro de la lógica de negocio. Nunca se sabe lo que te vas a encontrar, y se nos han dado casos de campos de los que estábamos completamente seguros que eran requeridos y hemos tenido que quitar la marca.
3. No se duplica información. Es decir, una de las reglas básica es que la misma información no puede estar en dos sitios, salvo…
4. En muchos casos, creamos campos calculados, que permiten acceder de forma rápida a información… por ejemplo, el importe pendiente de un recibo, en realidad, se calcula como el importe total del recibo menos la suma de los pagos parciales… como hacer este cálculo cada vez que nos hace falta ralentiza el funcionamiento del sistema, hacemos un campo calculado que se mantiene automáticamente (en nuestro caso, a través de Triggers de la base de datos). La información está duplicada en dos sitios, sí, pero por motivos de rendimiento (y siempre está sincronizada).
5. En los nombres de los campos no ponemos caracteres especiales (ni acentos, ni espacios, etc.). Aunque el gestor de base de datos lo admita, no lo hacemos, porque luego nunca se sabe desde dónde vas a tener que acceder.

Descripción de las entidades

El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos a tener. Según el caso de uso descrito, las tablas necesarias son las siguientes (al menos, son las que nosotros usamos):

• Cursos: almacena la oferta formativa del centro. Representa el catálogo o folleto que te dan al llegar al centro.
• Formas de Pago: para cada curso, las distintas opciones de pago que existen (es parte del folleto también). Trimestral, mensual, anual, etc.
• Grupos: dentro de cada curso, los diferentes horarios a los que se puede asistir. En este caso, el modelo que utilizamos es bastante más complejo que el que voy a describir aquí… en un artículo posterior lo describiré en detalle.
• Clientes: el que paga… puede ser el mismo que el alumno, pero también puede que no.
• Medios de pago: Contiene los diferentes métodos que los clientes pueden usar para pagar (contado, domicilación bancaria, etc), incluyendo las cuentas bancarias del cliente.
• Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas jurídicas), los alumnos son personas físicas. Un mismo cliente puede tener múltiples alumnos.
• Matrículas: Refleja en qué curso nos matriculamos, las fechas, la forma de pago, etc. De forma física, se refleja en el contrato que te dan para firmar.
• Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el centro.
• Pagos: esta tabla refleja los pagos que el cliente ha hecho (un recibo no necesariamente se paga de una vez). Como antes, la gestión de recibos y pagos que hacemos en realidad es más compleja de lo que voy a describir aquí. En otro artículo haré una descripción más completa.
• Alumnos en grupos: refleja los alumnos que están asignados a los distintos grupos. El alumno puede cambiar de grupo, y no queremos perder esa información histórica, así que necesitamos una tabla para gestionarlo.

Aquí podéis ver el modelo gráficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas… algunas líneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es ‘hija’ de otra, con la punta de flecha apuntando al padre.

Como podéis ver, sólo están indicados los campos que forman el modelo de datos… las claves primarias y las claves ajenas, que en cualquier caso deben estar ocultas al usuario final. En la siguiente sección describiremos los campos de cada tabla.

Campos para las entidades

Sólo describiré los campos más importantes, y no incluiré los campos de clave primaria y ajena que se describen en el gráfico.

Cursos

• nombre: varchar(100)
• descripcion: Memo. Se utilizará, en el contrato que se imprime para el cliente, para hacer una descripción larga del curso en el que el alumno se está matriculando. En uno de los sistemas que tenemos, en lugar de tener un campo memo, tenemos una tabla separada en la que se guardan, por tipologías, distintos campos memo, que se imprimen en distintos lugares del contrato.
• fecha_inicio: date
• fecha_fin: date

Formas de pago

• nombre: varchar(100)
• importe: float. Es el importe de cada recibo que se cobrará
• numero_meses: integer. El número de meses de cada recibo. Si es 1, se creará un recibo cada mes mientras dure la matriculación, si es 3, uno cada tres meses, etc. En algún sistema hemos hecho, en lugar de esto, una estructura de plantillas de recibos, con fechas, descripciones, etc. personalizadas. Eso permite más flexibilidad y más control, pero el modelo es bastante más complejo.
• numero_orden: integer. A la hora de presentárselo al cliente, poder mostrar primero las que más nos interesen.
• importe_matricula: float. Si además del importe del curso hay un importe de matrícula, se marca aquí.
• concepto_matricula. El concepto del recibo de matrícula, si creamos uno.

Grupos

• nombre: varchar(100)
• codigo: varchar(20). Siempre viene bien tener una codificación además del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el código del grupo en la Fundación Tripartita.
• fecha_inicio: date
• fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y además estas fechas no pueden estar fuera de las fechas del curso al que pertenecen.
• lugar: varchar(100) de impartición del grupo. En general, hacemos una gestión de aulas, pero eso lo ampliaré en otro artículo.
• notas: memo, del grupo
• horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por debajo de esta, pero no voy a entrar en tanto nivel de detalle ahora.
• maximo_alumnos: Integer. Máximo número de alumnos permitidos en el grupo.
• numero_alumnos: Integer. Es el número de alumnos existentes en el grupo. Este campo es de sólo lectura para el usuario, y es calculado, a través de una serie de Triggers en la base de datos, para poder saber rápidamente el número de alumnos activos en cada grupo sin tener que estar sumando.

Clientes

• nombre: varchar(100). En nuestros sistemas, normalmente, este es el único campo requerido (por código, no en la base) que tenemos. Así, el usuario puede dar de alta el registro aunque no tenga todos los datos, y volver después.
• primer_apellido: varchar(100)
• segundo_apellido: varchar(100)
• nombre_completo: varchar(300): Esto es un campo calculado, que se mantiene con Triggers, para poder coger de forma rápida el conjunto Nombre+’ ‘+primer_apellido+’ ‘+segundo_apellido
• direccion: memo
• codigo_postal: varchar(20): no hay que ser tacaño… de vez en cuando hay que meter una dirección extranjera y el código postal puede ser más grande.
• poblacion: varchar(50)
• notas_internas: memo
• etc. de datos personales (profesión, teléfonos, email, etc.)

Alumnos

• nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en clientes es sólo nombre por si
• primer_apellido: varchar(100)
• segundo_apellido: varchar(100)
• nombre_completo: varchar(300):
• etc. de datos personales (profesión, teléfonos, email, etc.)

Medios de pago

• tipo_medio: Integer. Normalmente tiene una tabla asociada con los tipos de medios de pago, que suelen ser: Sin Pago, Contado, Banco
• nombre_titular: varchar(100)
• direccion_titular: memo
• entidad: varchar(4)
• oficina: varchar(4)
• dc: varchar(2)
• numero_cuenta: varchar(10). Si el tipo_medio es banco, entonces se tiene que rellenar la información bancaria del cliente.
• por_defecto: boolean. Se suele preguntar el medio de pago, pero teniendo uno por defecto, para no tener que rellenarlo siempre. Normalmente, cada cliente, al crearse, se crea un medio de pago “contado”, y se le pone por defecto.

Matrículas

Además de los datos de curso, forma de pago, medio de pago, alumno y cliente (esto último puede parece redundante, pero no lo es… podemos tener el caso (yo lo he visto) de un alumno que se matricula para estudiar, digamos, inglés y francés… el inglés lo paga el padre y el francés la madre. Así, es necesario que cada matrícula esté asociada con el alumno, y también con el cliente), necesitamos los siguientes campos:

• fecha_inicio: date.
• fecha_fin: date.  Por defecto, las del curso, pero hay gente que puede matricularse después o terminar antes (si se da de baja, por ejemplo).
• importe: real. Por defecto, el de la forma de pago escogida, pero puede ser también distinto… descuentos por familiares, cosas así. Suele ser buena idea dejarlo abierto, para que el cliente lo pueda cambiar.
• motivo_baja: varchar(100). Normalmente, los motivos de baja son una tabla separada, para luego poder obtener estadísticas de número de bajas por tipo, cosas así.

Recibos

• fecha_emision: date
• fecha_cobro_completo: date
• numero_recibo: varchar(20)
• concepto: varchar(50)
• importe_recibo: float.
• importe_pendiente: float. Es un campo de sólo lectura, actualizado a través de triggers, que permite acceder a la información sin tener que sumar.

Pagos

• fecha: date
• importe: real
• forma_cobro: varchar(20). Normalmente es una tabla separada, igual que el caso de los tipos de baja. Puede ser: contado, transferencia, tarjeta, talón, etc.

Alumnos en grupos

• fecha_inicio: date
• fecha_fin: date. Suele ser una intersección entre la duración del grupo y la de la matrícula, pero cuando el alumno cambia de grupo, para una matrícula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta también la posibilidad de que en un mismo curso, pagando más, un alumno pueda asistir a varios grupos (esto también lo he visto).

Triggers y procedimientos almacenados

El modelo de datos y la lógica del negocio están muy estrechamente relacionados. Los sistemas de base de datos nos permiten desarrollar triggers y procedimientos almacenados, lo que es muy conveniente para dejar trozos de la lógica de negocio asociados con la base de datos, tanto por motivos de organización del código como por motivos de rendimiento (un procedimiento almacenado es varios órdenes de magnitud más rápido que hacer el mismo proceso a través de un lenguaje de programación).

En el ejemplo que estoy describiendo, hay varios triggers y procedimientos que se usan:

• Actualización de los campos “NombreCompleto” de alumnos y clientes: normalmente, es un trigger BEFORE INSERT y BEFORE UPDATE, que actualiza el campo en base al contenido del nombre y los apellidos.
• Actualización del campo “ImportePagado” de recibos, AFTER INSERT, UPDATE y DELETE de pagos, que actualiza el campo ImportePendiente de recibos como la suma de los pagos de ese recibo.
• Es habitual hacer un procedimiento CREARRECIBOS, que se ejecuta en el proceso de creación de la matrícula (o un trigger AFTER INSERT), que crea los recibos de la matrícula en base al importe y forma de pago seleccionadas.

En las próximas semanas continuaré esta serie de artículos, describiendo otros submodelos de sistemas que hemos desarrollado… algunas ideas que tengo:

1. Gestión de horarios y citas
2. Facturación
3. Gestión de horas trabajadas
4. Stock

Cualquier otra idea será bienvenida…

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

En todas las empresas, a día de hoy, hace falta software… ya sea para escribir cartas, para llevar la contabilidad o para publicar cosas en la web, sin software a día de hoy no se hace casi nada. Así que… ¿de dónde lo sacamos? Se me ocurren tres formas de obtener software (que en realidad son cuatro):

• Pagar por el software: ya sea pagar por licencias de uso de un software que ya existe, como comprar Windows o la Office, o pagando a empresas como nosotros para que os hagan el software a medida.
• Tener software pirata: hace unos años esto era, de largo, lo más común… pero creo que poco a poco va disminuyendo, cada vez hay menos. Entre las campañas anti piratería y los sistemas anti copia, con la conexión ubicua a internet esto es cada vez más difícil.
• Usar software libre. Es una alternativa muy atractiva, claro, por varias razones que ahora explicaré… sin embargo, hay que tener en cuenta un par de cosas, sobre todo en cuanto a las licencias a través de las cuáles se distribuye el software.

¿Software libre, o software gratis?

Puede ser una de las dos cosas, y también las dos… la confusión puede venir de la palabra free, que en inglés significa tanto ‘libre’ como ‘gratis’. Por eso, en inglés, cuando se habla de ‘free software’ se distingue entre free, as in beer (es decir, gratis, como en ‘cerveza gratis’) y free, as in speech (es decir, libre, como en ‘libre expresión’).

Yo entiendo software libre como el que está abierto a modificaciones externas… es decir, se permite el acceso libre al código fuente y a la documentación de desarrollo, de forma que cualquiera pueda obtener dicho software, y hacer el uso que necesite, siempre que se ajuste a los términos de la licencia de distribución del software que sea. Cuando alguien libera un software, lo hace bajo una licencia de uso; es decir, una serie de condiciones que hay que cumplir si usas ese software. Lo que puedes o no puedes hacer, por tanto, viene definido por los términos de dichas licencias. No me voy a extender en los términos de cada licencia, está bien explicado en la wikipedia, sino que me interesa más reflexionar sobre qué puedes y qué no puedes hacer con el software dependiendo de la licencia que tenga.

Es decir, puedes tener software libre que es gratuito (que es el caso más común, que todos conocemos), pero también hay otras alternativas: puedes tener software libre que no es gratuito (más abajo hablaré de ello), y software gratis que no es libre, como todo el software freeware de los 90.

La madre del cordero: el copyleft

La filosofía básica que envuelve a la licencia libre más restrictiva, la GPL, es lo que se llama el copyleft. Este concepto viene como oposición directa del copyright, y se basa en la idea de compartir libremente las obras producidas (no se aplica sólo a software, sino a cualquier obra de producción propia). La idea básica es la que cualquiera pueda acceder a tu software, en este caso, y hacer las modificaciones que quiera, las mejoras o los cambios, sin ninguna limitación y sin tener que pagar derechos de autor. Pero esto no significa que este modelo de licencia no tenga ninguna restricción, todo lo contrario. La idea es que, si el software que se ha liberado tiene copyleft, todas las derivaciones del mismo tienen que tener copyleft. Es decir, no se puede coger un software libre, hacer unas modificaciones, y generar un producto nuevo que no sea libre.  Cuidado, esto no significa en absoluto que no se pueda cobrar por el trabajo. GPL no significa gratis, sino libre.

A la hora de evaluar si podemos usar un software que está distribuido sobre una licencia libre tenemos que tener en cuenta qué es lo que vamos a hacer con él. Si es para uso privado, podemos coger el software, modificarlo, cambiarlo como queramos, no tiene ningún problema… el asunto viene cuando lo que queremos hacer es distribuir las modificaciones que hemos hecho… entonces es cuando entra en juego el asunto viral que tiene la GPL: cualquier producto que incluya software GPL como alguno de sus componentes, debe ser GPL a su vez.

Hay licencias menos restrictivas, como la LGPL, que permiten el enlace de software LGPL con software de otros modelos de licencia y licenciar el software obtenido de la forma que se quiera… lo fundamental de la licencia GPL es que todo lo que contenga al menos una linea de código GPL debe ser distribuido con la misma licencia

Libre no significa gratis necesariamente – un ejemplo con WordPress

O no habría nicho de negocio para nadie… ninguna de las licencias de software libre dicen que tenga que ser gratuito. Lo que dice la GPL es que el software que tú distribuyas debe serlo utilizando la GPL… es decir, puedes cobrar por el software, o por el trabajo, pero no puedes decirle al cliente que no puede distribuir libremente ni cambiar el software que le das, porque como está protegido por la GPL, tiene derecho a hacer lo que quiera dentro de la GPL.

Un ejemplo que estamos utilizando nosotros ahora: cuando los clientes nos piden que les hagamos desarrollos web, estamos utilizando WordPress para hacerlos (de hecho, nuestra propia página está hecha utilizando wordpress). WordPress está distribuido utilizando la licencia GPL y, por tanto, los temas (que son las adaptaciones que cambian el aspecto que tiene la página), también están sujetos a la licencia GPL (como se explica muy bien en este artículo). Esto significa que, si nosotros le desarrollamos un tema especializado a un cliente, nosotros no le podemos exigir al cliente que no cambie o distribuya dicho tema a quién quiera (bueno, nosotros podemos decir lo que queramos, pero el cliente no tiene por qué hacernos caso, ya que la licencia del tema tiene por fuerza que ser GPL). Si queremos, podemos poner una tienda de temas WordPress y que la gente los compre, siempre y cuando nosotros no limitemos las acciones de nuestros clientes dentro de la GPL.

Siempre había pensado que la GPL era una licencia muy restrictiva, y creo que es uno de esos problemas de lost in translation, ya que al leer “todo software derivado de GPL debe ser GPL”, y “GPL es una licencia ‘free’”, durante años he interpretado que todo software GPL debe ser gratis, y que los derivados también, y esto no es cierto. Una extensión a esta explicación, y un análisis de las implicaciones podéis leerlo aquí.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Para hacer desarrollo basado en tests es imprescindible tener un framework de desarrollo de tests para cada entorno de desarrollo que utilicemos. Hasta ahora, estamos usando los siguientes:

• Para Delphi, DUnit.
• Para Python, PyUnit.

Estas dos soluciones son buenas, ambas basadas en el framework de tests original de la eXtreme Programming, la JUnit. Cuando se programan tests de procesos no visuales, o se testean procesos de ataque a bases de datos, resulta bastante fácil tener el control… el problema viene cuando testeamos interfaces, que implica simular acciones de los usuarios; especialmente cuando lo que hay que testear es el interface de aplicaciones web.

En este caso concreto, nuestros criterios a la hora de seleccionar un framework son los siguientes:

• Que sea software libre: no quiero estar atado a un software propietario si es posible… muchos años de Delphi, Windows y SQL Server me dejan espantado.
• Que tenga un editor de macros, que permita que alguien que no sea programador grabe tests de forma fácil… así descargamos parte de la tarea del programador a la gente de soporte.
• Que tenga un plugin de integración con Hudson, para poder hacer pruebas regresivas.

Mirando por ahí, he encontrado dos:

• Un plugin de Firefox llamado Selenium, integrado con Hudson a través de un plugin. Permite grabar tests, agrupados en unidades, y funciona muy bien… hace bastante que no sacan versión nueva, y a día de hoy el plugin no funciona con Firefox 3.6. Por lo que veo, puede emular el funcionamiento de Firefox, Internet Explorer y Firefox en modo Chrome. La gestión de ficheros (guardar test cases, test units, cosas de esas) es un poco ‘caprichosa’, pero por lo demás me parece bastante estable.
• Windmill. Está programado en Python, es muy fácil de instalar si ya tienes Python montado. También tiene grabador de macros, pero yo he tenido peores experiencias que con Selenium, en términos de acciones que no se guardan bien, esperas a que la página cargue que no funcionan del todo bien y, no sé si tiene que ver, de repente mi Chrome ya no se conecta a Internet (y el Firefox sí, muy wraro).

He estado valorando los dos y me gusta más Selenium. Además, creo que es más usado que Windmill, y eso es muy importante a la hora de escoger un framework de cualquier tipo… ninguno queremos que deje de actualizarse el sistema que usamos.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

En este artículo se analiza el impacto en el desarrollo de videojuegos de la metodología ágil. Es un sector con algunas particularidades muy concretas, y coincido con el autor prácticamente en casi todo, aunque lo que hace es, básicamente, criticar los peores aspectos de la ‘ola ágil’.

Descripción de la metodolgía Scrum

Estoy completamente de acuerdo en su desprecio por el ‘fanatismo’… una cosa es que los conceptos teóricos del modelo de desarrollo ágil me convenzan, y otra cosa es utilizar Kanban o Scrum como palabras mágicas que van a resolver todos los problemas y nos llevan al paraiso en la tierra.

Primero, considero mucho más importantes los principios del manifiesto ágil que las metodologías que se desprenden de él. Me gusta el concepto de dar más prioridad al software funcional que a la documentación, pero eso no es una carta blanca que permite no documentar porque el proceso lo dice. No estoy diciendo con esto que las metodologías ágiles sean erróneas, sino que es muchísimo más importante, en mi opinión, tener un conocimiento de las ideas que hay detrás, y después desarrollar tu propia metodología, recogiendo las cosas que te resulten más útiles de unas u otras.

Como bien dice el autor del artículo, parece que ha llegado el momento en el que ‘Ágil’ y ‘Scrum’ son términos intercambiables, es decir, que la gente se queda con la parte ‘brillante’, que le da más juego a su currículum, y no con la teoría que hay detrás. Creo que es muy común haber salido de un proyecto manejado con los parámetros del desarrollo clásico tan espantado, que buscas cualquier cosa que te prometa que el siguiente proyecto va a salir mejor… como ha habido (o sigue habiendo) una moda de Scrum, te agarras a él, sin conocer muy bien de qué va la película, aferrándote al término como si fuera una varita mágica.

Me parece mucho menos importante seguir los preceptos del Scrum que utilizar las herramientas que se proponen como ayuda:

• Integración continua
• Desarrollo basado en tests
• Programación por parejas

…esas cosas, que tienen un impacto directo y fácilmente mensurable en el desarrollo del proyecto, y menos importante el hecho de dibujar en un tablón las cosas de una forma o de otra.

Hablando de desarrollo basado en tests, hay una parte interesante del artículo, en la que se menciona un estudio de Microsoft en el que se analizan datos empíricos de sistemas desarrollados utilizando el desarrollo basado en tests y otros en los que no. Creo que son relevantes los resultado. Cito (y traduzco yo mismo):

Los resultados de los casos de estudio indican que la densidad de errores pre-release [..] descendió entre un 40 y un 90% comparado con proyectos similares que no usaron TDD (desarrollo basado en tests).  Además de esto, los equipos experimentaron un incremento entre el 15 y el 35% de tiempo de desarrollo inicial desde la adopción del TDD.

Quiere decir que, al utilizar la TDD el tiempo de desarrollo en la fase inicial aumenta entre un 15 y un 35%, comparado con una disminución del nº de defectos muy superior. Para el autor del artículo, este incremento en el tiempo inicial de desarrollo no compensa ante el nº de errores eliminados, y en esto no estoy en absoluto de acuerdo. Es probable que nuestra diferencia de opinión se basa en que trabajamos en productos software distintos: para nosotros, cada sistema que desarrollamos está pensado para que nunca (mientras el cliente quiera) dejemos de trabajar en él, mientras que el desarrollo de un videojuego es un proyecto que tiene una fecha límite de presentación. Nosotros siempre pensamos en los proyectos a medio y largo plazo, y para esto, tener una buena suite de tests regresivos desde el principio es fundamental (de hecho, en proyectos antiguos los echamos de menos enormemente).

Finalmente, en lo que sí estoy de acuerdo, y lo que más me preocupa, es su afirmación de que el mayor problema de las empresas que afirman utilizar desarrollo ágil es que es muy fácil usarlo como una excusa para no hacer una buena dirección del proyecto, para no hacer planificación o para hacer una gran bola de barro teniendo la excusa de que “nosotros hacemos Scrum, así que tiene que funcionar”.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Antes de que nadie se me eche al cuello, esto no es un sesudo análisis del grado de penetración (con perdón) de las tecnologías de la información en las empresas españolas, ni nada eso… simplemente es una reflexión, basada en las empresas que hemos visto durante los últimos años, del uso que las empresas pequeñas le están dando a las TI para su trabajo diario.

En este caso, no estoy pensando tanto en ‘cuántos ordenadores tiene la empresa’, o cuánto dinero se gasta anualmente, sino en términos de cómo la informática, y especialmente el software, que es lo que más me interesa, altera la forma de trabajar la empresa (y si la mejora o no, claro). Además de escribir cartas, correos electrónicos y navegar por Internet, la parte que más me interesa es qué hace la gente para ayudarse en la gestión de la empresa… ¿cómo facturan? ¿cómo llevan la base de datos de clientes? ¿tienen alguna?

El solitario, famoso solitario

Todos sabemos que, mal que bien, prácticamente cualquier empresa actual tiene al menos un ordenador en la oficina, casi siempre uno por trabajador, pero… ¿qué hace la gente con ellos? ¿jugar al solitario? Me gustaría reflexionar sobre hasta dónde llegan las empresas en términos de software.

Correo electrónico, la sempiterna office y bases de datos Excel por doquier

Dejando de lado algunas empresas en las que el uso del ordenador se limita a ocupar espacio, creo que al menos aquí llegan la mayoría de las pequeñas empresas que conozco: tienen una cuenta de correo (normalmente una por empleado) y llevan su gestión a través de una mezcla, mejor o peor, de hojas de Excel, tablas Access y documentos Word.

Todos los años de versiones piratas de la Office (ya que estoy: coged la OpenOffice, que es gratis o usad alguna de las alternativas libres que hay online) han hecho que, mal que bien, todo el mundo se maneje con Word y Excel.

Así que, como es lo que tienes a mano, es lo que utilizas… para tener una base de datos de clientes, te haces una Excel y vas guardando los datos. Luego, para hacer la facturación, o haces las facturas directamente en Word, o las haces en Excel, que es más fácil de formatear… al final, parece que la Excel vale para todo (y es así en algunos casos). Así, el encargado de facturación tiene su Excel con las facturas. El comercial, otra en la que lleva la lista de clientes, la gente de producción sus propias hojas para controlar el trabajo, etc.

Que nadie me entienda mal… esto funciona, y en muchos casos la empresa no necesita nada más. Ya sabéis lo que dice la piedra angular de la informática… si funciona, no lo toques. Ahora bien, hay veces en que ya sea la complejidad de los procesos (muchos datos que hay que gestionar o cruzar) o simplemente el tiempo, hacen que esto no sea cómodo. Principalmente, lo que pasa, es que las Excel se hacen tan complejas, sobre todo cuando la gente aprende a usarla mejor, que nadie las puede comprender salvo el que las ha hecho (para ejemplo, este fantástico artículo sobre ‘la gran hoja Excel‘).

Llegado a este momento, la siguiente fase:

La aplicación de gestión

Una vez llegado a este punto (y creo firmemente que en la PYME hay que pasar por el anterior y llegar a su umbral para pasar a la siguiente fase), pasamos a buscar un programa de gestión que esté pensado para nuestro negocio. El ejemplo más claro es la contabilidad… creo que a día de hoy no hay ninguna empresa que no tenga un software de contabilidad para su gestión. También es verdad que la mayoría tiene la contabilidad subcontratada a una gestoría, así que está un poco más oculto.

Igual que con la contabilidad, la empresa tiende a buscar o bien un software para facturar y llevar la cartera de clientes, o bien un software para gestionar su proceso productivo (lo que más le preocupe). En algunos casos, las dos cosas.

Me quitaréis la Excel de mis manos frías y muertas!

Aquí empieza una gran batalla, que durará mucho tiempo… conseguir que la gente que ha trabajado duramente para conseguir una hoja Excel con muchísima funcionalidad deje de utilizarla, y se ponga a usar una aplicación completamente nueva, de la que en muchos casos no se fía.

Esta pelea puede durar años, y he visto situaciones en la que la gente llega a trabajar el doble: por un lado rellena los datos en la aplicación de gestión, porque se lo dice el jefe, y por otro tiene su Excel que es lo que utiliza para trabajar. En fin!

Una vez todo el mundo, más o menos, se acostumbra a usar la aplicación, las cosas mejoran sensiblemente: se reduce la duplicación (aunque no se elimina del todo), los procesos tediosos se acortan y se tiene más información (que no conocimiento) sobre lo que pasa en la empresa.

Creo que para la mayoría de las Pymes esta situación es suficiente… han resuelto lo que llamo el ‘día a día’, es decir, no se les pierde información, no dejan de cobrar facturas porque se les olvida que estaban pendientes, los clientes están todos atendidos y controlados, etc. Todos contentos.

O casi todos, porque hay algunas situaciones en las que esto no es suficiente: cuando el proceso de la empresa es un poco particular, o cuando no encuentras una aplicación estándar que te satisfaga. Aquí, muchas empresas caen en un pantano:

Tengo un amigo que es informático, nos hace un programa por cuatro duros

Muchos de los que hayan pasado por esta etapa (que puede ser que vaya antes de la etapa del software estándar, depende) sentirá un escalofrío por la espalda al recordarla… es aquél momento en el que alguien de la empresa propone hacer un programa a medida, por varias posibles razones:

• Las aplicaciones que hay en el mercado no nos convencen… nuestra forma de hacer las cosas es particular.
• Son caras, podemos hacernos una más barato si la hacemos nosotros (los pelos de punta sólo de escribir esto).
• Hacemos una, y la vendemos, así al final nos sale gratis y tenemos un programa como nosotros queremos.
• Buscamos una solución de software libre, y la adaptamos.

Puede ser alguna de estas razones o una combinación de varias, pero mucha gente se encuentra en esta situación.

El caso de la solución de software libre es un poco especial, y es la mejor opción si es posible: si es un proyecto activo, que tiene muchos programadores colaborando, el software será bueno; en cualquier caso, hay que conseguir a alguien que se encargue de la programación que haga falta.

En algunos casos es uno de los trabajadores de la empresa, que tiene conocimientos de programación, o el hijo/hermano/primo de alguien de la empresa (perdón por el sexismo, también hay hijas, hermanas y primas) el que se hace cargo, como parte de su trabajo si es un empleado o cobrando poco dinero si es un allegado… con la mejor voluntad del mundo, se pone Access y Visual Studio en ristre a programar lo que la gente de la empresa le va pidiendo. En otros casos, se contrata a un programador Freelance, por un precio fijo, para que programe lo que necesitamos.

Una vez más, el disclaimer: a mucha gente esto le funciona bien, y tienen una aplicación que les sirve para lo que necesitan. Sin embargo, también hay dos situaciones muy comunes:

• El empleado o allegado se cansa o se va, por esas circunstancias de la vida, y el proyecto se queda a medias o esbozado. Conclusión: tiempo perdido por parte de todos.
• El programador se da cuenta del marrón en el que se ha metido: se pactó un precio cerrado y como la especificación no hace más que cambiar, el tiempo de trabajo se dispara. En estas circunstancias, y dependiendo de la experiencia del programador, o bien ejerce de pringao y sigue adelante, o se planta y pide más dinero, y empiezan las peleas.

Si hay suerte, llegamos a tener una aplicación que funciona bien y que cumple los requisitos actuales de la empresa… se ajusta bien y tiene los informes que hacen falta.

Igual que en todos los casos anteriores, muchas empresas pueden quedarse aquí tan contentas, pero hay una cosa a tener en cuenta: eventualmente, la forma de hacer las cosas de la empresa puede cambiar. Puede ser un cambio de legislación (el ejemplo clásico: el IVA codificado en bruto al 16%, ahora que está a punto de subir al 18), o una decisión de la dirección de la empresa de cambiar la forma de hacer las cosas: mejorar el proceso, que es algo que todas las empresas deberían hacer continuamente.

Aquí se presenta un problema: ¿modificamos la aplicación que hay? puede ser que el programador que la hizo ahora se dedique a otras cosas y no le interese… también puede ser que la aplicación esté tan liada que ya no haya quien le meta mano (lo que se llama la gran bola de barro). El único que puede hacer algo en la aplicación es el programador que la hizo, y ni siquiera está claro que le interese.

En esta situación hay varias alternativas: o la empresa se vuelve a un sistema estándar del mercado, o se lía la manta a la cabeza y hace uno nuevo con otro programador, o hace lo que creo que es peor para todos, y lo que pasa a menudo: ajusta su forma de trabajar a la aplicación de gestión que tiene… así se pierde ventaja competitiva, todas las empresas acaban haciendo más o menos lo mismo, que es lo que dictan las aplicaciones de gestión del mercado.

La otra opción, que es la que me parece mejor (eso estaba claro, porque es a lo que nos dedicamos), es buscar una empresa que sea capaz de hacer desarrollo a medida, y si es posible que tenga una plantilla de sistema que se pueda adaptar…

Un sistema de información que vaya contigo

El objetivo llegado a esta fase es intentar no repetir los problemas del pasado:

• No duplicar la información: si es posible, tener un sistema que englobe toda la actividad de la empresa.
• Tener una aplicación que pueda modificarse con el tiempo, no algo completamente cerrado.
• No quedarte ‘colgado’, confiar en una empresa que vaya a estar contigo años.

En realidad, todo esto es lo que se llama un ERP, no una aplicación de gestión: es un sistema informático que funciona como un mapa de todo lo que pasa en la empresa… centraliza toda la información que se produce y maneja en el sistema y permite procesarla a posteriori para extraer conocimiento.

El fantástico mundo de los consultores

Si tienes unos pocos de cientos de miles de Euros, vas a las grandes compañías del mercado, y te implantan lo que se llama una solución sectorial. Es más o menos lo que describía en al final del punto anterior: una plantilla de sistema de información del sector de la empresa, y que un equipo de consultores y programadores adaptan a tus necesidades.

Que nadie se engañe aquí: si se hacen las cosas de forma medianamente correcta, al final la empresa va a tener un sistema fantástico, que puede ser modificado a posteriori y que es extremadamente estable, porque está implantado por diversos equipos en infinidad de empresas.

Ahora bien, esto tiene un precio, y si estamos hablando de las grandes consultoras… ese precio no es pequeño. Sólo el importe de las licencias es tremendo, a lo que hay que añadir las horas de consultoría y adaptación necesarias para tener un sistema como el que necesitas…

¿Y si eres una empresa pequeña de verdad? Si no te puedes gastar 60.000 Euros en un sistema de información, qué haces? pues lo tienes chungo, la verdad… buscar una empresa que pueda hacerte un desarrollo a medida y que tenga todas estas cosas en la cabeza.

Qué voy a decir a estas alturas… cuento esto porque describe lo que hemos estado haciendo los últimos años, y lo que entiendo que debe hacerse en las Pymes… nosotros hemos hecho aplicaciones estándar durante mucho tiempo, y siempre nos hemos encontrado con los mismos problemas… la gente quiere cambios continuamente, así que me parece que ese modelo no se ajusta del todo a lo que la gente quiere…

Poco más tengo para contar de este tema… con un poco de suerte tú que lees esto identificarás la fase en la que se encuentra tu empresa, y este artículo te servirá de ayuda para saber por dónde seguir (o para avisarte de los peligros que hay en la carretera).

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Somos un equipo de fanáticos de la programación a medida. Utilizamos métodos ágiles de desarrollo para que nuestros clientes puedan tener software hecho a medida, que cambie según sus necesidades y a un precio ajustado.

Para nosotros es fundamental que puedas saber el estado de tu proyecto; por eso tenemos múltiples métodos para que estés informado en tiempo real de nuestros progresos.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

Atributos Los campos del modelo entidad-relacion no siempre representan información sobre el modelo de negocio que están tratando. A menudo, son campos auxiliares que ayudan a la implementación del modelo dentro de la base de datos. Los atributos del modelo Clase-Colección representan siempre información sobre el modelo de negocio. Si es necesario algún campo auxiliar en alguna tabla, es completamente transparente tanto para el usuario como para el analista (y en la mayoría de los casos para el desarrollador). Por otro lado, además de los tipos de datos clásicos en una base de datos (carácter, numérico, fecha, etc.) en este modelado se incluyen otros dos tipos de atributos. En general, en el modelo Clase-Colección existen tres tipos de atributos: Atributos de tipo valor, de tipo objeto y de tipo colección. La incorporación más importante del modelo clase-colección es la asociación de los atributos tipo objeto y tipo colección en parejas. Como decíamos antes, en el modelo entidad-relación las relaciones se ven siempre desde un único punto de vista a la hora de modelizar. Como en el mundo real, las relaciones en un modelo de negocio siempre tienen dos puntos de vista, y nuestro modelo de datos intenta representar eso. Una relación se representa por un par de atributos, enlazados entre sí. De esta forma, no hay que pensar en estructuras predefinidas y ver cuál se adapta mejor, sino analizar la realidad y representarla de la mejor forma posible. Más adelante lo veremos con más detalle. A continuación se hace una pequeña introducción a los tres tipos de atributos:Todos los que programamos sistemas de información para empresas tenemos que tener conocimientos de modelado de datos en bases de datos relacionales. Bases de datos y SQL son habilidades imprescindibles para nuestro trabajo.

Desde siempre ha habido cosas que no me han acabado de convencer del modelo entidad-relación, o mejor dicho, de la implementación que los sistemas de bases de datos relaciones hacen del mismo. Hay algunas cosas que no me han parecido naturales, y hemos desarrollado una teoría que, al menos a nosotros, nos ha servido los últimos 5 años para los proyectos que hemos desarrollado.

Cosas raras en el modelo entidad-relación (con todo respeto)

Nuestra teoría (la llamamos, a falta de un término mejor, el modelo objeto-colección) se basa dos ideas, aparentemente sin nada que ver una con la otra:

Primero, la programación orientada a objetos (estaba claro, habiendo en el título la palabra “objeto”). Segundo, la idea de que las relaciones siempre se pueden ver, de forma distinta, desde el punto de vista de las dos entidades involucradas…

En la implementación de una relación 1 a N entre dos tablas, la relación se establece creando una clave ajena que ‘apunta’ a la tabla ‘madre’. Sin acceder a los metadatos de la base, no se puede saber, mirando una tabla, cuántas tablas están relacionadas con ella. Es como si la relación sólo se estuviera viendo desde el lado de la tabla ‘hija’, sólo desde un punto de vista. No nos ‘suena’ bien.

Otra cosa es la implementación de las relaciones M..N. Implica la existencia de una tabla intermedia en la que se almacenan las duplas de claves ajenas que representan la relación. En teoría (nos enseñaban en la facultad), cada entidad tiene que tener una representación física en el sistema que estamos modelizando, y durante las clases se pasaba de puntillas por el hecho de que estas tablas eran ‘auxiliares’, que ayudaban a montar la relación pero no tenían existencia como entidades. Hmpf!

Lo que hacemos

Proponemos una forma similar, pero ligeramente diferente, de entender las relaciones, y una forma de implementarla utilizando los sistemas de base de datos relacionales existentes actualmente.

• ¿Quieres suscribirte a los comentarios de este Post?
• Compartir con Facebook
• Añdirlo a Google Reader
• Compartir con LinkedIn
• ¡Compártelo en Twitter!
• ¡Compártelo con Digg!

En lugar de hacer sistemas a medida, vamos a coger sistemas ya existentes, que son estables y que funcionan bien, y vamos a buscar una forma de que se comuniquen… no hace falta que todo esté en la misma base de datos.