Sintaxis y semántica

Según la Real Academia Española, la sintaxis (que deriva del latín y del griego con significado “coordinar”), es la “parte de la gramática que enseña a coordinar y unir las palabras para formar las oraciones y expresar conceptos” o el “Conjunto de reglas que definen las secuencias correctas de los elementos de un lenguaje de programación”, y la semántica es el “Estudio del significado de los signos lingüísticos y de sus combinaciones, desde un punto de vista sincrónico o diacrónico”. Donde estudio sincrónico significa con independencia de la evolución temporal, aplica a una época dada, mientras que diacrónico considera la evolución temporal.

Similares aunque más completas definiciones y detalle, aparecen en la Wikipedia.

Entonces… ¿por qué y para qué hablamos de la sintaxis y la semántica de los datos? … ¿con qué sentido se aplica? ¿cómo afecta a la calidad de los productos que construimos?

Sin duda, en primer término afecta a la calidad porque la información que los sistemas proveen, derivan de los datos. Y la información es la que hará o no que el sistema resulte útil a clientes, consumidores, usuarios diversos.
Y porque en la actualidad, la información también es una importante base de intercambio, se provee y/o analiza, hasta se compra y se vende y desde luego, puede provenir de distintas fuentes de datos: se requerirá consistencia semántica aparte de conocer su sintaxis. Fluye y cambia en tiempo real, entre sistemas y plataformas cada día más complejos y fuera de nuestro control: se requerirá integración.

“Sintaxis” y “semántica” aparecen en el mundo de los sistemas de información y las ciencias de la computación con diversos significados o sentidos y asociadas a importantes conceptos como estructura de datos, modelos de datos, lenguajes de modelado de información, metadata,  interoperabilidad, etc.

Ambos aspectos, sintaxis y semántica, nada nuevos, juegan un importante rol en relación a las características de calidad de los datos, como las propuestas en ISO/IEC 25012 [1].

Por ejemplo:

• Ambas afectan a la exactitud (Accuracy) de los datos.
• La sintaxis de los datos, su estructura y secuencia, se relaciona también con su característica de calidad precisión (Precision).
• La semántica de los datos (diacrónica), su significado y combinación en el tiempo, se relaciona también con su actualidad (Currentness).

Entonces, vale que pensemos en la semántica y la sintaxis de los datos que manejan o almacenan nuestras aplicaciones, porque finalmente pueden resultar en colaborar en deleitar a los interesados, o en un fracaso del producto.

---
[1] ISO/IEC 25012 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Data quality model.

Calidad de datos – Another brick in the wall?

Es indudable que la calidad es un viaje, más que un punto determinado. A lo mencionado en otros post sobre la calidad del producto y la calidad en uso, debemos agregarle la calidad de datos.

Imaginemos por un momento el mejor software, el más rápido, seguro y de gran usabilidad, pero que no es confiable en la información que muestra o actualiza, ya sea en su valor o en su representación.

¿Lo apreciaríamos como de calidad? Seguramente no.

En ese sentido la ISO 25000, a través de su estándar 25012, hace un aporte interesante, al aplicar un criterio similar al propuesto para la calidad del software, es decir características que definan la calidad pero esta vez de los datos retenidos en el sistema.

Lo interesante de la propuesta es que esas características, 15 en total, están divididas en dos grandes categorías, aquellas que dependen de los datos en sí mismo: inherentes - valores en un dominio, relaciones entre los valores de los datos, metadatos, y aquellas dependientes del sistema – cómo son accedidos, almacenados y preservados.

Demos algunos ejemplos:

Inherentes:

Exactitud (accuracy): ¿Sirve para lo que quiero guardar?

Completitud: ¿Tiene toda la información y relaciones que necesito?

Credibilidad: ¿Podré confiar en que sus valores son verdaderos?

Actualidad (currentness): ¿Estará “fresco” o vigente cuando lo utilice?

Dependientes del sistema:

Disponibilidad: ¿Podré acceder si tengo permisos, cuando lo necesite, aún durante respaldos y a la vez que otros usuarios?

Recuperabilidad: ¿Podré volver a su estado previo luego de una falla?

Inherentes + Dependientes del sistema:

Precisión (precision): ¿Representará fielmente lo que necesito?

Trazabilidad: ¿Podré saber quién lo accede y modifica?

La calidad de los datos puede tenerse en cuenta entonces desde que estos se diseñan, durante su recolección y procesamiento, y hasta que se descartan.

El otro tema a tener en cuenta es que este modelo de calidad de los datos es transversal a los diferentes sistemas / software, preservando así la calidad a lo largo de ellos. Esto unifica y mantiene los aspectos funcionales, arquitectónicos y de usabilidad. El modelo de calidad de los datos podría ser diseñado e implementado independientemente del sistema / software que utilice esos datos.

Ampliando la pirámide entonces podríamos representarlo así:

Indicadores accionables

Indicador accionable. Qué es eso?

Pensemos en un indicador de negocio y pensemos también que su valor o tendencia indique que alguna parte de este negocio va bien o mal, traducido: estamos ganando o perdiendo dinero.

No es sencillo imaginarlo. Los indicadores financieros de alto nivel, parecen de poca utilidad, ya que su variación depende de muchas variables, entre las cuales la pieza de software es sólo una más.

Difícilmente una persona cercana al producto de software pueda concluir de este tipo de indicadores de alto nivel algún mal funcionamiento o mejora y repararlo.

Entonces?
Varias preguntas a responder, desde qué rol cumplimos nosotros respecto a la Organización y a su negocio, hasta cuál es el negocio: 

Nuestra posición: Pueden presentarse al menos dos casos bien diferenciados, y pueden darse algunas cuestiones inherentes a la Organización que se relacionan fuertemente con lograr estos indicadores accionables:
Desarrollamos software para el negocio. Podemos ser externos o internos a la Organización. 

Caso 1: Somos proveedores externos. Fabricamos  y allí terminamos nuestra intervención. Los indicadores que interesan a nuestro negocio como organización proveedora, serán los típicos de los proyectos tiempo-costos-alcance. Cumplido esto, habremos entregado un producto de calidad de acuerdo a lo especificado.

Caso 2: En el segundo caso (internos a la Organización), estamos en la segunda categoría. Estamos dentro del negocio. Somos parte integrante de él.
El negocio no necesita ser el negocio completo de la Organización; por ejemplo, en un banco el negocio del que hablamos podría ser su área de home banking y aplicarse estas ideas a ese área. En este caso valen los primeros indicadores, pero se agregan otros indicadores de éxito. Aquéllos que relacionan el comportamiento del negocio de home banking con el comportamiento del software que lo soporta.


Otras preguntas: Relacionadas con cuestiones inherentes a la Organización que se relacionan fuertemente con lograr estos indicadores accionables:

En relación al negocio: 
Puede el negocio traducir su comportamiento (si gana o pierde) en indicadores que sean accionables, es decir que se pueda tomar una acción en base a ellos?. Y que tales indicadores a su vez estén relacionados lo más cercanamente posible al producto de software?
Esta es una pregunta difícil y el tema también lo es. La relación raramente es tan directa y los indicadores dependerán de qué podemos medir para determinar ese comportamiento. Por ejemplo: conversiones de visitas en ventas de otros productos bancarios, abandonos, incidentes, motivos de quejas de clientes.
. 
En relación a la cultura de la Organización: 
Es capaz la Organización de abrir ese tipo de información (si gana o pierde como en el ejemplo anterior del home banking) a sus áreas normalmente consideradas técnicas y de servicio, o esa es información que no se difunde?.


Ejemplo de Indicadores por nivel de la pirámide.