Arquitecturas web y los buscadores

Hola de nuevo,

En esta entrada vamos a hablar de la estructura general de ÁTICA y cómo permitir que los robots de los buscadores puedan explorar los contenidos públicos de manera que salgan en sus resultados. Puede resultar chocante esta mezcla de temas, pero todo tendrá sentido en su momento.

Aplicaciones web

Es difícil definir el concepto de aplicación web con exactitud sin usar lenguaje muy técnico, de hecho es un tema que daría para varias entradas. Sin embargo la idea intuitiva es sencilla: es una aplicación que se ejecuta a través de un navegador web, ni más ni menos. ¿Ejemplos? Gmail, Facebook, Séneca (la aplicación de gestión docente de la Consejería de Educación de Andalucía) e incluso cualquier periódico digital actual. En definitiva, cualquier sitio web cuyo contenido no sea estático y, por tanto, sea capaz de reaccionar a las acciones del usuario que accede a ellas.

Algunas de las ventajas de una aplicación web frente a una aplicación de escritorio tradicional son la ubicuidad (mientras haya una red que conecte la aplicación con el usuario), el soporte de varios usuarios simultáneos y, si está bien hecha, la independencia del sistema operativo y navegador usado por el usuario.

Ojo: una aplicación web no implica que los contenidos deben accederse remotamente a través de una red. De hecho, puede instalarse una aplicación web en local y funcionar perfectamente aunque con ello perdemos parte de sus ventajas.

Por supuesto, ÁTICA es una aplicación web.

Arquitectura de una aplicación web

Como es lógico, no todas las aplicaciones web son iguales. La forma que tienen de obtener la información, procesarla y presentarla al usuario varía de unas a otras, al igual que los métodos de interacción del usuario con la aplicación. Dado que en una aplicación web intervienen muchos elementos (un navegador web, uno o varios servidores, bases de datos, etc.) es muy común describir una aplicación indicando qué funcionalidad realiza cada uno de esos elementos. A esa descripción se le denomina arquitectura de una aplicación web.

¿Cuáles son esas funcionalidades? Depende de la fuente consultada, pero el consenso general suele distinguir tres grandes funcionalidades: presentación, lógica de aplicación y almacenamiento.

  • Presentación: Es la que permite al usuario elegir qué información necesita, se la muestra y le permite interactuar con ella.
  • Lógica de aplicación (o lógica de negocio): Es la encargada de implementar el comportamiento de la aplicación (calcular la suma de una factura, realizar avisos, realizar búsquedas, etc.)
  • Almacenamiento: Como su nombre indica es el lugar donde los datos se guardan y son recuperados posteriormente para poder llevar a cabo la lógica de negocio.

Por supuesto, esta clasificación no es única ni aplicable a todos los casos.

En las aplicaciones tradicionales de escritorio, todas las funcionalidades están integradas en la misma entidad: el programa. En una aplicación web (exceptuando las locales) suelen estar repartidas como mínimo en dos elementos: el navegador web y un servidor. A cada uno de esos elementos se les denomina tier y esto nos permite definir varias arquitecturas web dependiendo del número de tiers: 2-tier, 3-tier y, en general, n-tier (cuidado, se ha sacrificado exactitud técnica en las definiciones para facilitar su comprensión).

Pongamos como ejemplo una arquitectura 2-tier, también conocida como cliente/servidor y que es de las más comunes en las aplicaciones web clásicas:

2tier_1

En este caso, el cliente o navegador web (Chrome, Firefox, Internet Explorer, etc.) solamente tiene como responsabilidad mostrar la información que le indique el servidor y de indicar a este último cuando el usuario interactúa con los datos (por ejemplo, pinchando un enlace). Todo el almacenamiento y procesado de los datos se realiza en el servidor, el cliente es meramente una «ventana» dibujada por el navegador.

Cada una de esas funcionalidades estará implementada por una o varias tecnologías. Por ejemplo: lo que el navegador muestra al usuario suele ser una página descrita mediante HTML y CSS en la que se incluye el contenido y cómo debe presentarse. La lógica de aplicación del servidor genera esa información dirigida al navegador mediante algún lenguaje de programación tipo PHP, JSP, Ruby, ASP.net, etc. Los datos que se necesitan para ello se obtienen de algún sistema gestor de bases de datos como Oracle, MySQL, MSSQL, MongoDB, etc.

2tier_2

Sin embargo, todos esos detalles quedan ocultos al usuario final, como no puede ser de otra forma.

Un ejemplo de arquitectura 3-tier sería aquella que coloca el almacenamiento en otro servidor distinto de manera que pueda ser accedido por varios elementos de lógica de aplicación simultáneamente. Es la evolución lógica si la demanda de la aplicación aumenta y queremos que el tiempo de respuesta se mantenga rápido.

Por otro lado, últimamente están proliferando las aplicaciones web donde parte o la totalidad de la lógica de aplicación se traslada directamente al navegador. ¿Por qué? Entre otras cosas, descarga al servidor de responsabilidades que el cliente puede realizar sin mucho esfuerzo pues los navegadores actuales son muy capaces a la hora de ejecutar código. Otro de los motivos suele ser que permite reducir la cantidad de información que se envía por la red, pues sólo se solicitan aquellos datos imprescindibles en un momento dado.

2tier_3

Pongamos un ejemplo sencillo: Imagina una aplicación que permite listar los pedidos realizados. Una aplicación web que tenga la lógica de aplicación en el cliente permitiría solicitar solamente aquellos pedidos que caben en la pantalla e iría pidiendo más silenciosamente conforme el usuario vaya avanzando en la lista. También permitiría realizar operaciones de filtrado con los datos previamente enviados sin tener que solicitarlos de nuevo o podría calcular la suma del importe de los pedidos seleccionados sin molestar al servidor.

En estos casos, el papel del servidor casi se reduce a ser un simple intermediario con la base de datos. Si la aplicación está bien diseñada, esto repercutirá en una mayor capacidad de servicio pues podrá atender más solicitudes con los mismos recursos.

Por supuesto, en la realidad es muy fácil encontrar modelos mixtos que no son estrictamente como los dos ejemplos que hemos descrito sino algo intermedio. Un ejemplo lo tenemos en Séneca, donde la mayoría de la lógica de aplicación se encuentra en los servidores de la Junta pero alguna funcionalidad se ejecuta desde el navegador (por ejemplo, desplegar un menú o seleccionar un conjunto de estudiantes para realizar una operación sobre ellos).

¿Y ÁTICA? La versión actualmente desplegada es casi un 100% similar al primer ejemplo, donde toda la carga recae sobre el servidor. Este modelo ha tenido lógica en tanto el servidor normalmente se encuentra en el mismo centro y tiene una carga baja de usuarios. Pero la nueva versión soportará más de un centro bajo el mismo paraguas, con lo que es posible que el número de operaciones y, consecuentemente, el tráfico aumente.

Todo esto nos lleva a que la próxima revisión de la plataforma trasladará parte de la carga de trabajo al cliente, lo que debería aumentar la velocidad de respuesta aunque el cliente se encuentre lejos del servidor mientras se reduce la carga de trabajo de este último.

Hay muchas formas de implementar la lógica de aplicación en el cliente. Entrando en detalles técnicos, en nuestro caso estamos usando AngularJS y Javascript, de manera que los datos se solicitan al servidor cuando se necesitan mediante una interfaz RESTful.

Aplicaciones en el navegador y los buscadores

No todo es de color de rosa cuando damos trabajo al navegador. Uno de los problemas que originalmente se atribuían a esta arquitectura es el soporte para dispositivos móviles, pues no suelen contar con mucha capacidad de procesamiento o de memoria. Afortunadamente, hoy en día no es el caso. La mayoría de los dispositivos móviles actuales tienen una capacidad razonable y, además, soportan la mayoría de las tecnologías web modernas. De hecho, el mayor inconveniente para usar una aplicación en un dispositivo móvil no suele ser éste, sino las limitaciones del tamaño de la pantalla y de interacción del usuario (un dedo no es tan preciso como un ratón). Por supuesto, también existe una solución para esto: el diseño adaptativo (responsive design), pero eso es materia para otra entrada.

Ya comentamos antes que íbamos a relacionar la arquitectura web con los buscadores, y aquí está el motivo: un buscador descarga páginas web de los servidores y las analiza para indizarlas e incluirlas en sus resultados. Los grandes buscadores suelen realizar esas descargas mediante la utilización de bots o arañas (spiders), que no son más que programas que se bajan páginas, las analizan y descubren nuevos enlaces en ellas que posteriormente son también descargados. Una vez han recibido los contenidos de una página, se incluyen en el índice del buscador. El proceso se repite hasta cubrir la mayor parte de la telaraña de la web.

¿Cuál es el problema entonces? En el caso de las aplicaciones web donde la lógica de aplicación está en el navegador, la página que se descarga del servidor no suele incluir datos sino simplemente un esquema o plantilla que luego se rellena con información obtenida dinámicamente según las acciones del usuario. Tampoco suelen incluir todos los enlaces posibles porque muchos se generan dinámicamente por el propio navegador.

Por tanto, si la aplicación tiene toda la lógica en el navegador, es más que probable que un buscador no pueda tener acceso a la información que nos gustaría que apareciera en los resultados.

Para variar Google ya ha pensado en esto y ha creado una guía para los programadores que, de seguirse, permite que sus robots puedan acceder a información descargada dinámicamente por la aplicación. Resumiendo mucho, lo que hace es avisar al servidor para que éste le envíe «instantáneas» de cada sección de la aplicación en lugar de lo que tiene que ejecutarse en el navegador.

Pero la solución por la que hemos optado es mucho más sencilla. Lo primero es plantearse qué necesitamos que sea analizado por un buscador, y en nuestro caso es solamente la parte pública, es decir, aquellos documentos que el administrador local ha marcado para que se puedan descargar sin que un usuario entre en la aplicación.

Dado que el acceso público es independiente del acceso de usuarios registrados y no es muy complejo de implementar, el nuevo ÁTICA procesará la parte pública completamente en el servidor en lugar de «compartir» la carga con el navegador. ¡Problema solucionado!

Si tenéis dudas o sugerencias, dejad un comentario. ¡Hasta la próxima!

Enlace permanente a este artículo: https://blogs.iesoretania.es/atica/2013/03/31/arquitectura/

Soporte multicentro

Hola a todos,

Antes de nada aprovechamos la ocasión para mostrar una captura (muy) provisional del aspecto que tendrá la portada de ÁTICA. En ella se mostrará toda la información marcada de acceso público, por ejemplo la misión del centro o los criterios de evaluación y corrección. Esto es un avance respecto al acceso de invitados que había previamente y del que hablaremos dentro de poco.

Invitado

Hoy volvemos a la carga, esta vez para explicar un aspecto muy importante que una aplicación como ÁTICA debe cumplir: el soporte multicentro. Para ello, vamos a echar mano de la experiencia acumulada con otras versiones.

Introducción y motivación

Hasta ahora, el modelo de datos de ÁTICA sólo soportaba un único SGC y, por tanto, un único centro educativo. La razón es que la aplicación se concibió para ser instalada de forma individual, pues no había muchos centros interesados en su implantación en un primer momento.

Sin embargo, con el tiempo, el grupo de trabajo de ÁTICA ha ido añadiendo en su seno más centros. De hecho, actualmente está formado por tres: I.E.S. Ntra. Sra. de la Cabeza (Andújar), I.E.S. Oretania (Linares) e I.E.S. Pablo de Olavide (La Carolina). Esto ha creado una nueva necesidad: la de mantener actualizadas tres plataformas separadas, tarea que, de hecho, no resulta fácil. La prueba es que hemos necesitado varios meses para poder poner en funcionamiento la misma versión en los tres sitios. Además, antes de realizar el despliegue de cada cambio es necesario realizar una serie de pruebas que prevengan (en lo posible) problemas con la nueva funcionalidad.

Una posible solución pasaría por compartir el mismo código de la aplicación para todas las plataformas. Así, cualquier cambio se reflejaría instantáneamente en todos los centros, independientemente de su número. Por eso, la nueva versión de ÁTICA lleva el soporte multicentro implantado desde la médula. A este concepto se le conoce como multi-tenancy en el mundo de la arquitectura software.

Ventajas:

  • Dar soporte a una única instancia facilita el despliegue de actualizaciones.
  • Las copias de seguridad pueden ahora ser centralizadas. Además, se pueden tomar medidas adicionales para aumentar la disponibilidad del servicio, como sistemas de alimentación ininterrumpida o conexiones de red redundantes en un único servidor y se beneficiarían todos los centros.
  • Se puede compartir información entre varios centros educativos, como por ejemplo, los usuarios.

Inconvenientes:

  • Complica un poco el modelo de datos interno que usa la aplicación, pues ahora hay que distinguir a qué centro u organización pertenece cada aspecto.
  • La seguridad debe reforzarse para evitar que documentos de una organización sean accesibles desde otra por personal no autorizado.
  • Un fallo de despliegue afectará a todas los centros alojados en la instancia. Antes, si el despliegue de un centro fallaba no se aplicaba la actualización a los demás hasta localizar el problema.

Aún así, lo mejor de esta característica es que permite mantener el modelo anterior de una instancia por centro sin problema alguno, en cuyo caso la mayoría de los inconvenientes se esfuman. Por tanto, es mucho más flexible.

Detalles técnicos

Aparte de los cambios en el modelo de datos, hay otros aspectos técnicos que hemos tenido que resolver. Aquí comentamos algunos de ellos:

¿Cómo se realiza la gestión de usuarios?

Los usuarios son compartidos para todos los centros educativos. Eso quiere decir que un usuario puede formar parte de cualquier número de ellos, pero siempre tendrá el mismo nombre de usuario y contraseña. Para «homogeneizar» el acceso se ha decidido recomendar que el nombre de usuario sea su usuario IdEA pues todos el personal de los centros educativos de la Consejería de Educación de la Junta de Andalucía tiene uno.

Como es lógico, cuando acceda el usuario a cada centro sus perfiles podrán ser (y seguramente serán) distintos.

¿Cómo y quién administra la aplicación?

Ahora se distinguen dos tipos de administradores: el administrador general y el administrador local. El primero se asigna manualmente a uno o varios usuarios y podrá crear/eliminar instancias o realizar cambios que afecten a todos los centros. Lógicamente, debe restringirse su uso lo máximo posible.

Por otro lado, el administrador local está asociado a un perfil especial, como por ejemplo el de «Coordinador/a de Calidad» o el de «Director/a». Todos aquellos usuarios que tengan ese perfil en un centro dado podrán realizar cambios que afecten solamente a dicho centro. Algunas de sus tareas típicas implican la creación del árbol documental o la gestión de usuarios.

Se ha estudiado la seguridad de este modelo para evitar ciertos tipos de ataque.

Por ejemplo: «Un administrador local podría añadir a su centro a un administrador general y, una vez es usuario de su centro, cambiar su contraseña a una conocida. A partir de ahí, sólo tendría que salir y volver a entrar como el usuario suplantado para tener permisos de administrador general».

Por ello se ha decidido restringir el cambio de contraseñas en algunos casos. Por ejemplo: un administrador local puede cambiar cualquier contraseña de un usuario de su centro salvo que dicho usuario sea administrador general o pertenezca a un perfil de administrador local en algún otro centro. Esto elimina muchos riesgos potenciales. Un administrador general no tiene esas limitaciones.

¿Cómo facilitamos que los usuarios accedan al centro correcto?

Se han barajado varias posibilidades:

  • Reconocer el centro por la URL desde la que se intenta acceder a la aplicación. De esta forma se pueden usar registros CNAME que apunten al mismo servidor y la aplicación distinguirá el centro. Un ejemplo no-técnico: se puede configurar que «atica.iesoretania.es» y «atica.iescabeza.es» apunten al mismo servidor web. Cada vez que se reciba una solicitud, se comprueba a cuál de los dos nombres se refiere el navegador y da acceso directo al centro correspondiente.
  • Añadir un parámetro a la dirección de entrada a la página web que distinga entre un centro y otro. Por ejemplo: si el usuario pincha un enlace que apunte a «www.atica.org.es/?o=1» se entra en un centro y si el enlace contiene «www.atica.org.es/?o=2», le lleva a otro.
  • Si no hay información suficiente para distinguir de primeras a qué centro quiere ir el usuario, se puede mostrar un menú para que lo elija manualmente.

Multicentro

  • Se accede siempre a la misma dirección y la aplicación analiza si la petición de conexión procede de la Red Corporativa de la Junta de Andalucía para intentar deducir de qué centro viene. El problema de esta opción es que impide que un usuario pueda acceder a la instalación de otro centro, pues siempre se le redirigirá a aquel donde se encuentra.

Todas ellas están implementadas actualmente salvo la última, que aún está en estudio.

Conclusiones

La nueva característica aporta flexibilidad a ÁTICA y permite instalarla en un sitio centralizado para dar servicio a más de un centro simultáneamente, simplificando la administración, facilitando el despliegue de actualizaciones y reduciendo el tiempo entre que se detecta un problema y se soluciona en todos los centros.

La próxima entrada tratará un problema que suelen sufrir las aplicaciones web modernas: cómo soportar que los motores de búsqueda indicen los contenidos públicos de forma correcta. ¡Hasta la próxima!

Enlace permanente a este artículo: https://blogs.iesoretania.es/atica/2013/03/29/multicentro/

La ISO 9001:2008 en un centro educativo (II)

Volvemos a la carga con la aplicación de la norma a un centro educativo. En esta entrada vamos a centrarnos en varios conceptos: los registros, las auditorías, las no conformidades y las acciones.

Ya comentamos anteriormente que, resumiendo mucho, un sistema de gestión de la calidad tiene como objetivo que todas las tareas que se desarrollen en un centro estén perfectamente explicadas, que se lleven a cabo correctamente y que se realicen en el momento adecuado. Además, se trata de un proceso de mejora continua, es decir, busca que las cosas se hagan cada vez mejor.

Para realizar esto, es necesario que quede constancia de la realización de algunas acciones: ¿Cuándo se ha entregado una programación? ¿Se ha comprobado que la recepción de cierto material se corresponde con el pedido? Básicamente, en eso consiste un registro: un mecanismo que permite dejar constancia (registrar, de ahí el nombre) que se ha hecho algo y, si es necesario, cuándo y quién la ha llevado a cabo. Los registros tienen responsables, que son los encargados de cumplimentarlos y custiodarlos. Por ejemplo: jefatura de estudios debe mantener y guardar un registro donde aparezcan las programaciones entregadas por los distintos departamentos, si su contenido se adapta a un modelo determinado y la fecha en la que se produce el depósito.

¿Cuándo se comprueban esos registros? Puede hacerse en cualquier momento, pero los registros cobran especial importancia durante las auditorías. Las auditorías son revisiones completas y exhaustivas del sistema de gestión de calidad. Se puede hablar de dos tipos de auditorías: auditorías internas y auditorías externas.

Las auditorías externas se realizan por personal de la empresa certificadora y, por tanto, ajeno al centro. Por otro lado, en las internas, puede ser personal propio o de otros centros educativos. La regla de oro es que nadie puede auditar su propio trabajo o los procesos de los que es responsable.

En una auditoría suelen revisarse todos los procesos para comprobar si están bien definidos y, sobre todo, si están llevándose a cabo de la forma correcta. ¿Cómo puede saber una persona ajena al centro si se ha realizado esta u otra acción? Pues comprobando los registros asociados. Para ello los solicitará a su responsable y verificará si cumplen con las especificaciones del proceso (por ejemplo, que el 95% de las programaciones se entreguen antes de que comience el mes de noviembre). Otras veces, el auditor querrá comprobar él mismo que los datos de los registros son veraces mediante un muestreo. Así, podría solicitar programaciones a un jefe de departamento para asegurarse de que cumple con los requisitos a pesar de que el registro diga que es así. Por último, hay acciones que no se pueden reflejar en un registro porque sería incómodo o tedioso (¿aplica un profesor los criterios de calificación correctamente a sus alumnos?). Aquí se suele recurrir también al muestreo.

La siguiente pregunta que queda en el aire es, ¿qué es lo que ocurre cuando se encuentra algo que no es correcto? Pues que se abre lo que denominamos una «no conformidad» o NC. En resumidas cuentas, una no conformidad es la constatación de que no se está actuando conforme a lo que indica el SGC, a la norma ISO o a la legislación aplicable al centro educativo. Existen dos tipos según su importancia: menores y mayores. Las últimas son de un calibre tal que el centro no puede recibir la certificación ISO hasta que se solucionen.

Una no conformidad debe ir acompañada de mucha información: qué es lo que no se hace correctamente, ejemplos de dónde se ha detectado (se denominan evidencias), una estimación del alcance que puede tener el problema y qué apartados de la norma no se han cumplido.

Las NC pueden abrirse en cualquier momento, no sólo en las auditorías. Por ejemplo, pueden abrirse al terminar una sesión de evaluación o cuando se entregan las programaciones si algo no cumple con lo previsto. De hecho, el no haber detectado o respondido adecuadamente a una no conformidad justo cuando los indicadores indican que hay algo mal supone una no conformidad en sí misma.

Una observación importante: No es malo tener no conformidades, todo lo contrario. Una no conformidad indica que existe algo que no se hace bien y que podemos mejorar, lo que es el objetivo único de un sistema de gestión de la calidad.

Lo que sí está claro es que abrir una no conformidad es sólo el primer paso: una vez detectado el problema hay que solucionarlo. Para ello, a partir de un análisis de causas de dicha NC, se procederá a definir una o más acciones correctivas y/o reparadoras. Las correctivas indican qué vamos a cambiar o hacer para evitar que se vuelva a producir de nuevo mientras que las reparadoras intentarán corregir los efectos no deseados que son consecuencia del problema detectado.

Todas las acciones tienen una una fecha de comprobación en la que se hace una revisión para asegurarse de que se llevan a cabo. Una vez revisadas pueden cerrarse si todo está en orden o derivar en otras acciones si todavía es necesario hacer todavía más. Una NC no se puede cerrar hasta que todas sus acciones han sido cerradas con éxito.

Independientemente de ésas, existen las acciones preventivas. Se abren cuando se detecta que algún indicador todavía está en un valor aceptable pero que su tendencia es a empeorar, con lo que tarde o temprano se saldrá de los límites permitidos y provocará una no conformidad. Por tanto consisten en la toma de medidas que eviten ese desenlace.

Resumiendo: los indicadores de un SGC y las acciones que hay que controlar suelen incluirse en registros. Esos registros se comprueban para ver si todo está correcto, especialmente durante las auditorías. Cuando se detecta que algo no se hace según lo especificado, se genera una no conformidad y un conjunto de acciones correctivas y reparadoras para mitigar el problema y que no vuelva a aparecer. Por último, si detectamos que algo tiende a ir cada vez peor, podemos abrir acciones preventivas para intentar evitar que se abra una NC.

Y con esto terminamos la lista de conceptos básicos sobre un SGC que pretendía explicar. Como siempre, dejad algún comentario si tenéis alguna pregunta o propuesta.

Enlace permanente a este artículo: https://blogs.iesoretania.es/atica/2012/12/06/iso9001-2008-2/

La ISO 9001:2008 en un centro educativo (I)

Antes de meternos en faena con el proyecto hemos pensado que puede ser interesante explicar qué es un sistema de gestión de la calidad (SGC), qué es la ISO 9001:2008 y cómo se aplica todo esto a un centro educativo.

Ojo, esta entrada no pretende ser exhaustiva ni mucho menos, simplemente se trata de introducir estos conceptos para hacernos una idea de la motivación que nos llevó a realizar la aplicación.

Empezamos con una idea intuitiva. Todo el mundo entiende que detrás del trabajo que se realiza en un centro educativo existe mucho más que preparar e impartir clases o hacer pruebas al alumnado. ¿En qué consisten esos «trabajos» adicionales? Hay muchas tareas que no suelen verse: incorporar nuevos estudiantes, planificar qué se va a enseñar durante el curso, la atención a padres y madres, compras de material, las prácticas de empresa (en formación profesional), etc.

Dado que todas estas tareas son realizadas por muchas personas, es importante asegurarse de que cada una de ellas sabe qué tiene que hacer y, sobre todo, cómo debe hacerlo. Es más, para estar seguros de que se ofrece un servicio adecuado a la comunidad educativa será necesario establecer controles que nos permitan cerciorarnos de que todo lo que hay que hacer se hace en tiempo y forma. No podemos corregir ningún problema si no lo detectamos antes.

Pues bien, esto es lo que nos ofrece un sistema de gestión de la calidad (SGC para los amigos): divide las tareas que han de realizarse en un centro educativo en partes, detalla qué ha de hacerse en cada una de ellas y cómo podemos comprobar que, efectivamente, se han llevado a cabo. Si hay algún problema, se definen mecanismos para investigar las causas y solucionarlo.

Ahora toca el turno a la norma ISO 9001:2008. Según la Wikipedia, «especifica los requisitos para un sistema de gestión de la calidad que pueden utilizarse para su aplicación interna por las organizaciones, para certificación o con fines contractuales«.

En román paladino viene a significar que explica cómo implementar un SGC. Pero la gracia del asunto es que cuando un SGC sigue la norma ISO 9001:2008 existen organizaciones externas reconocidas que pueden certificar que nuestra implementación cumple con sus requisitos. Es decir, que garantizan a todo el mundo que no sólo tenemos claro qué es lo que tenemos que hacer sino que nos preocupamos de comprobar que lo estamos haciendo bien. Al resultado de obtener esa garantía se llama certificación, y suele plasmarse en un logo que seguramente hayas visto antes:

Hay un número limitado de entidades que puedan emitir certificaciones, proceso que además no es precisamente barato. Además, las certificaciones hay que renovarlas periódicamente para asegurar que se siguen manteniendo las condiciones.

Entonces, ¿para qué gastar dinero en una certificación? ¿Qué es lo que aporta? La certificación es una garantía de que no se trabaja sin criterio ni control. Por tanto, hay empresas y organismos que no tienen relaciones contractuales con otras empresas que no estén certificadas por la ISO 9001:2008.

En el caso de un centro educativo no es más que un indicador de que se preocupan por hacer las cosas bien, y que tienen mecanismos para detectar y rectificar cuando algo no funciona como estaba previsto. Cuidado, esto no quiere decir que en estos centros se aprenda más o mejor, pues eso depende de muchos factores que no son controlados por el SGC como la capacidad del profesorado y del alumnado o de los medios disponibles.

La normativa que afecta a la actividad de los centros educativos, a sus usuarios y a quienes trabajamos en ellos es variada y, a veces, compleja. Un SGC nos aporta unos procedimientos de trabajo diseñados de manera que garanticen que se cumple esa normativa, sin tener que andar indagando qué puedo o debo hacer en cada actividad que se realiza en el Centro. En definitiva, el objetivo es conseguir que se planifique todo lo que se va a hacer y que se haga todo lo que se dijo en su momento que se haría. Por otro lado, también debe ser suficientemente flexible para que cada centro pueda decidir cómo quiere organizar su gestión y su funcionamiento, permitiendo además obtener datos para evaluar la marcha del centro en todos los ámbitos de su actividad, con la referencia siempre de la satisfacción de los implicados en ella.

Por tanto, lo que nos aporta un SGC es que salten las alarmas en muchas situaciones no deseables: un profesor que no planifica sus clases, un grupo de estudiantes que no asiste a clase como norma, corrección de exámenes «a voleo», tutores que no responden, proveedores que no cumplen con sus obligaciones, etc. Si se detecta una desviación, el SGC habilita una serie de mecanismos para investigar el motivo y proponer una solución para corregir el problema y evitar que vuelva a ocurrir.

Lógicamente, para poder detectar estas situaciones se hace necesario contar con muchos controles. Cada vez que se hace algo importante, hay que dejar constancia de su realización, incluyendo quién, cuándo y cómo (si fuera relevante). Otras veces se realizan encuestas de satisfacción a los distintos miembros de la comunidad. Todo esto implica un esfuerzo y una carga para todos los miembros del centro educativo (lo que a veces levanta ampollas), pero es necesario para poder asegurar de que no existen desviaciones en el funcionamiento.

Además, si sumamos que todas las acciones importantes tienen que estar bien definidas, un SGC mueve una cantidad ingente de documentación e información que cambia continuamente. Es aquí donde entra ÁTICA: su misión es dotar a un centro educativo de una herramienta que permita gestionar toda esta vorágine de documentos y controles para facilitar la aplicación de un SGC a los miembros de la comunidad educativa.

En una próxima entrada explicaremos los conceptos básicos que se utilizan en la ISO 9001:2008, pues son claves para entender el modelo de datos y los escenarios de uso de la aplicación.

Espero que os haya sido útil. No dudéis en dejar comentarios si tenéis alguna pregunta o algo más que aportar.

Enlace permanente a este artículo: https://blogs.iesoretania.es/atica/2012/06/28/iso9001-2008-1/

Todo tiene un comienzo…

Hola a todos,

Tenemos un nuevo proyecto en ciernes, y es tan grande que vamos a necesitar ir paso a paso aprendiendo cada día. En concreto se trata de una aplicación web para la implantación de sistemas de gestión de la calidad ISO 9001:2008 en centros educativos: ÁTICA.

Para ser sinceros, no partimos de cero. Desde hace un par de años venimos utilizando una aplicación con el mismo nombre y que realiza esta misma función en dos institutos de la provincia de Jaén.

La idea es aprovechar esa experiencia para construir una nueva aplicación y, de paso, tomar contacto con las nuevas técnicas de programación web. Durante este tiempo hemos detectado puntos fuertes y, también, carencias importantes que trataremos de solucionar. Poco a poco iremos desgranando las limitaciones de las versiones iniciales y cómo pensamos evitarlas.

Por supuesto, la aplicación resultante será software libre bajo licencia AGPL, lo que significa que cualquiera podrá aprovechar el esfuerzo colectivo invertido en ella con la condición de que las correcciones y mejoras que se realicen reviertan a la comunidad.

Resumiendo: ¿de qué vamos a hablar en este blog? Pues un poco de todo: clientes y servicios web, servicios RESTful, Javascript, librerías, documentación, modularidad, patrones de diseño, traducción, pruebas, despliegue de aplicaciones, cloud computing, diseño de modelos de datos e incluso de dinámicas de grupo (tenemos que coordinar a varios centros).

Os animo a comentar, proponer y criticar (constructivamente, eso sí). Mucho del terreno que vamos a pisar es pantanoso para nosotros y cualquier opinión será bien recibida.

¡Comenzamos el viaje!

Enlace permanente a este artículo: https://blogs.iesoretania.es/atica/2012/06/26/todo-tiene-un-comienzo/