Recopilar requisitos para modelos semánticos

Planificación de un modelo semántico para tu producto o proyecto

Contar con los requisitos adecuados es esencial para diseñar, crear y entregar datos para soluciones de BI que aporten valor al negocio. Si diseñas lo incorrecto para el problema equivocado (o ni siquiera identificas el problema), tu solución está destinada al fracaso… incluso si usa las funciones o tecnologías más recientes y sigue todas las mejores prácticas. Pero ¿cómo puedes abordar la recopilación de requisitos para modelos semánticos? ¿Qué aspectos deberías tener en cuenta y qué herramientas o métodos pueden ayudarte?

En esta serie, compartimos consejos para crear de forma eficaz un modelo semántico. En el artículo anterior, definimos qué es un modelo semántico, cómo es uno bueno y los pasos típicos para crear un modelo semántico.

En este artículo, describimos consideraciones clave para recopilar requisitos con los que diseñar y crear modelos semánticos. También explicaremos cómo puedes usar Tabular Editor para crear wireframes del modelo y cómo puedes usar esos wireframes en prototipos o, más adelante, para acelerar el desarrollo de tu modelo semántico.

El proceso de recopilación de requisitos

En general, antes de empezar a crear un modelo semántico, deberías iniciar la planificación de la solución de BI (artículo de Microsoft – Power BI Implementation Planning). El primer paso de la planificación de la solución es recopilar los requisitos adecuados. Es un paso esencial para asegurarte de que diseñas e implementas el modelo correcto, que aborda los problemas de negocio adecuados para el público adecuado. El objetivo del proceso de recopilación de requisitos es asegurarte de que defines y entiendes suficientemente los problemas o preguntas de negocio correctos que debe abordar el modelo semántico:

1. Prepararse para recopilar requisitos: Lleva a cabo una planificación práctica para reunir a las personas y los recursos necesarios para el proceso de recopilación de requisitos.
2. Recopilar requisitos de negocio: Define el alcance del modelo y recopila los datos y las soluciones de BI existentes con ese mismo alcance, si están disponibles. Después, implica a las partes interesadas en talleres interactivos para entender el problema de negocio. Describe de forma colaborativa cómo se abordará este problema; por ejemplo, con maquetas de Reports, flujos de usuario o una propuesta sencilla por escrito.
3. Recopilar requisitos técnicos: Traduce los requisitos de negocio identificados en el Paso 2 a especificaciones técnicas. Normalmente, este es el paso en el que diseñas un modelo semántico, basándote en una comprensión del producto final deseado para los usuarios.
4. Planificar la implementación: Realiza una planificación práctica para reunir los recursos necesarios para empezar el desarrollo.

Durante el proceso de recopilación de requisitos, deberías asegurarte de que estás respondiendo a preguntas clave sobre tu modelo semántico. Las respuestas a estas preguntas determinan el enfoque que adoptarás en el diseño del modelo.

Responde a preguntas clave

En las secciones siguientes se describen algunas preguntas importantes que deberías responder sobre tu modelo semántico. Son ejemplos y no necesariamente representan una lista exhaustiva que cubra todos los escenarios.

Preguntas sobre cómo se usará el modelo

• ¿Cuántos modelos necesitas crear?
  ¿Necesitas uno o más modelos? ¿El alcance se solapa con modelos existentes que usa el negocio hoy, o existe un requisito para que varios modelos “hablen” entre sí?
  • Decidir entre un único modelo más grande o varios modelos más pequeños implica muchos factores. Por lo general, conviene priorizar escenarios en los que los modelos se centran en preguntas/problemas de negocio concretos, en lugar de convertirse en una amalgama de “todos los datos que el negocio podría necesitar”.
  • El reporting multifuncional puede ser un requisito complejo, y es importante definir desde el principio cómo lo abordarás (p. ej., drill-through entre Reports, modelos compuestos, otros…)

• ¿El modelo dará servicio a Reports centrales o también lo consultarán usuarios de autoservicio?
  ¿El modelo dará servicio solo a Reports centrales o los consumidores de contenido con permisos de creación podrán conectarse al modelo semántico y consultarlo?
  • Los modelos de autoservicio requieren un esfuerzo adicional para organizar y documentar el modelo, como añadir carpetas de visualización y descripciones de objetos.
  • Los modelos de autoservicio pueden requerir un esfuerzo adicional para garantizar que DAX sea flexible y con buen rendimiento para las consultas que los usuarios puedan generar.
  • Los usuarios de autoservicio pueden requerir mentorización/formación y gestión del cambio específicas para entender cómo usar el modelo (p. ej., en lugar de intentar hacer grandes volcados de datos en Analyze in Excel con todos los datos al nivel de detalle más bajo).

• ¿Qué cargas de trabajo downstream y elementos de datos de Fabric usarán este modelo?
  ¿El modelo se usará solo en elementos de reporting de Power BI (como Reports o Reports paginados) o también se usará en otras cargas de trabajo de Fabric (como notebooks o reflex)?
  • Puedes organizar los modelos para que sean más fáciles de encontrar y usar en estas cargas de trabajo, pero algunos elementos (como modelos compuestos) tienen una gran cantidad de consideraciones/limitaciones especiales que deberías conocer desde el principio, antes de implementarlos y usarlos.
  • Para algunas cargas de trabajo posteriores pueden aplicarse consideraciones especiales de gobierno (p. ej., para garantizar que los datos no se dupliquen en un reporting redundante, hat-on-a-hat).

• ¿Qué herramientas cliente (como Power BI Desktop o Excel) se conectarán al modelo y lo usarán?
  ¿El modelo se usará solo desde Power BI Desktop o también desde otras herramientas como Excel (Analyze in Excel o tablas con conexión en vivo) o Tableau Desktop?
  • Algunas funcionalidades (como parámetros de campo y cadenas de formato dinámicas para medidas) no funcionarán en todas las herramientas cliente, porque dependen de propiedades pensadas para Power BI Desktop.
  • Algunas herramientas cliente pueden permitir que los usuarios vean objetos ocultos (como Power BI Desktop), lo que significa que debes tener especial cuidado para no exponer objetos irrelevantes o sensibles.

• ¿Qué funciones específicas (como traducciones o perspectivas) podrías necesitar?
  ¿Necesitas implementar distintas configuraciones regionales para traducir objetos del modelo? ¿Los usuarios de los Reports esperan usar personalize Visuals o seleccionar perspectivas al crear modelos compuestos?
  • Crear y mantener traducciones o perspectivas puede suponer un esfuerzo adicional importante (p. ej., te cuesta más tiempo).

• ¿Qué hará realmente la gente con los datos una vez los tenga?
  ¿Se espera que los usuarios exporten datos (el 99,9 % de las veces… sí)? En ese caso, ¿qué harán con los datos una vez exportados? ¿Qué tipo de decisiones toman o qué acciones realizan basándose en los Reports que usan o en las consultas que hacen?
  • Entender esto ayuda a orientar el diseño de tu modelo semántico para que puedas tomar decisiones que apoyen los objetivos de los usuarios, a la vez que reduces riesgos.

Preguntas sobre los datos subyacentes

• ¿Hay consideraciones especiales de seguridad o cumplimiento normativo que debas tener en cuenta?
  ¿Necesitas seguir normas o regulaciones específicas para cumplir con requisitos de información confidencial, por ejemplo en seguridad de datos (seguridad a nivel de filas o seguridad a nivel de objetos) o prevención de pérdida de datos (como etiquetas de confidencialidad o directivas DLP)?
  • La seguridad de los datos tiene un impacto importante en el diseño y la implementación de tu modelo.
  • Las etiquetas de confidencialidad restringen ciertas funcionalidades, como la integración de Git de Fabric, y conllevan diversas consideraciones y limitaciones, como la herencia de etiquetas en elementos posteriores.

• ¿Cuáles son los data sources a los que necesitas conectarte y usar?
  ¿Qué Data sources se usarán? ¿Necesitas un on-premises data Gateway o un VNet Gateway? ¿Qué modo de almacenamiento se usará para estos Data sources?
  • Algunos Data sources pueden requerir atención especial en conectores, Gateways, seguridad, rendimiento o modo de almacenamiento.
  • Hay varios pros y contras que considerar para cada modo de almacenamiento (Import, DirectQuery y Direct Lake) que van más allá del alcance de este artículo.

• ¿Hay convenciones de nomenclatura específicas que debas seguir?
  ¿Hay convenciones de nomenclatura específicas o poco habituales a las que debas ajustarte? Si no existen, ¿cómo vas a nombrar los campos de forma consistente para que a la gente le resulte fácil encontrar lo que necesita (y sepa qué es)?
  • Los campos del Data source pueden tener nombres distintos de los que usa el negocio.
  • Es posible que herramientas y Reports existentes ya utilicen convenciones de nomenclatura que los usuarios conocen.

• ¿Qué frescura de datos necesitan los usuarios?
  ¿El negocio necesita datos “en tiempo real” (de verdad los necesita)? Si no, ¿con qué frecuencia debe actualizarse el modelo? ¿Con qué frecuencia se actualizan los datos aguas arriba?
  • Los distintos requisitos de frescura de los datos pueden impulsar decisiones clave, p. ej., sobre el modo de almacenamiento.
  • Los modelos en Import mode pueden requerir distintos tipos de políticas de actualización (actualización incremental).

• ¿Se necesitan transformaciones en Power Query (o incluso más aguas arriba)? ¿Cuáles?
  ¿Los datos quedarán listos para el negocio si todas las transformaciones se hacen aguas arriba? ¿Necesitarás realizar transformaciones en Power Query y, si es así, cuál es el alcance de esas transformaciones?
  • Puede que no tengas acceso a herramientas o sistemas en origen para transformar los datos.
  • Las transformaciones de Power Query requieren esfuerzo adicional para garantizar una actualización del modelo con buen rendimiento.

Preguntas sobre el ciclo de vida del modelo

• ¿Quién dará soporte al modelo después de que se despliegue en producción?
  ¿Le darás soporte una vez que esté desplegado en producción (y lo use el negocio)? Si no, ¿quién?
  • El personal de soporte tendrá que entender el modelo y debería participar desde el inicio de su desarrollo.
  • Identificar e involucrar pronto al personal de soporte puede reducir el tiempo de traspaso y evitar confusiones o interrupciones tras el despliegue en producción.

• ¿Colaborarás durante el desarrollo del modelo?
  ¿Trabajarás con otras personas en el mismo modelo, lo que exigiría procesos más maduros y robustos? ¿Otra persona creará elementos aguas abajo o se encargará de la base de datos en origen?
  • La colaboración suele requerir control de código fuente, por ejemplo usando la integración de Git de Fabric (con archivos .pbip) o Azure Pipelines (con archivos de metadatos del modelo).
  • Coordinarse de forma eficaz con equipos y personas que trabajan aguas arriba/aguas abajo del modelo semántico es fundamental para garantizar productividad y éxito.

• ¿Cómo gestionarás los objetos de Report?
  ¿Necesitas objetos de Report para admitir funcionalidades específicas de Visual de Power BI?
  • Los objetos de reporting deberían organizarse separándolos del resto del modelo y, idealmente, ocultarse (por ejemplo, en su propia tabla de medidas), ya que se crean para un contexto único y específico, y no son útiles para escenarios generales.

• ¿Dónde y cómo documentarás el modelo?
  ¿Documentarás el modelo en una wiki, un documento de Word o de alguna otra forma? ¿Tienes pensado comentar el código de Power Query (M), el código DAX o añadir descripciones de objetos? ¿Has tenido en cuenta el tiempo necesario para hacerlo bien en tu planificación?
  • Una documentación correcta lleva tiempo y rara vez se contempla en la planificación del proyecto.
  • Decidir pronto una forma ligera y sostenible de documentar el modelo puede ahorrarte muchos dolores de cabeza más adelante; especialmente al integrarlo con procesos de planificación (p. ej., en DevOps).

• ¿Esperas cambios o ampliaciones futuras del modelo y cómo deberían gestionarse?
  ¿Cambiará el alcance del modelo con el tiempo, o su adopción crecerá hacia una audiencia más amplia? ¿Cómo se gestionarán esos cambios?
  • Planificar y anticipar el cambio garantiza que el modelo sea escalable y flexible.
  • Decidir pronto una forma ligera y sostenible de documentar el modelo puede ahorrarte muchos dolores de cabeza más adelante; especialmente al integrarlo con procesos de planificación (p. ej., en DevOps).

Diseña el modelo: wireframing en Tabular Editor

A estas alturas deberías tener un conocimiento suficiente de las preguntas y problemas del negocio que este modelo semántico debe abordar. También deberías tener un conocimiento suficiente de los requisitos técnicos de tu modelo semántico, al responder preguntas como las descritas en las secciones anteriores. A continuación, tendrás que diseñar tu modelo.

Al diseñar un modelo, puede ser útil crear un wireframe. Un wireframe es un modelo sin datos; esencialmente, solo estás creando el diagrama como abstracción del modelo… el diseño.

Figura 2: Un diagrama del modelo que muestra un wireframe de un modelo semántico de Power BI en Tabular Editor.

Como Tabular Editor funciona en modo desconectado (es decir, no en modo conectado, y no necesitas datos ni una conexión activa persistente a una base de datos), puedes crear un wireframe del modelo usando metadatos del modelo. Esto tiene varias ventajas:

• Validar suposiciones: Probar suposiciones sobre requisitos de negocio o técnicos antes del desarrollo, lo que puede ahorrarte tiempo más adelante.
• Mejores estimaciones: Entender mejor el esfuerzo y el tiempo necesarios para desarrollar el modelo, especialmente si ya organizas el wireframe.
• Crear una estrella guía: Representar los requisitos técnicos con un diseño real de modelo semántico, para que quede claro para todo el mundo cuál es el resultado previsto.
• De wireframe a prototipo y a modelo semántico: Como estás trabajando en Tabular Editor, tu wireframe se puede adaptar fácilmente a un modelo funcional.

Crear un wireframe en Tabular Editor es sencillo. Solo tienes que crear un modelo nuevo y empezar a añadir objetos sin ningún origen de datos.

Cómo crear un wireframe de modelo semántico en Tabular Editor

1. En Tabular Editor, crea un modelo nuevo y guarda los metadatos.
2. Crea objetos de tabla o cópialos desde modelos existentes y similares.
3. Añade las expresiones compartidas que puedas necesitar (p. ej., para parámetros de la cadena de conexión). No olvides configurar “Type” como “M”.
4. Crea las columnas que esperas tener en cada tabla. Asegúrate de especificar las propiedades:
   • Tipo de datos: El tipo de datos de la columna (p. ej., Integer).
   • Ordenar por columna: Si esperas un orden no estándar (p. ej., el nombre del día de la semana ordenado por el n.º de día de la semana).
   • Columna de origen: El nombre de la columna en el origen (p. ej., normalmente el mismo que el nombre de la columna).
5. Crea un diagrama del modelo y arrastra y suelta campos para crear relaciones.
6. Crea tablas calculadas para casos específicos como tablas de fechas o parámetros de campo.
7. Crea grupos de cálculo para casos específicos como inteligencia temporal o sustitución de medidas.
8. Crea medidas DAX para agregar columnas de forma explícita o para campos / KPI identificados como estratégicamente importantes en los requisitos de negocio.
9. Crea los roles previstos para la seguridad de datos, así como los permisos de tablas y objetos, si ya se conocen.
10. También puedes configurar propiedades clave (como política de actualización) u organizar el modelo (en carpetas de visualización o grupos de tablas).
11. Guarda el modelo y el diagrama, y haz una captura del diagrama como representación visual del wireframe.

Más adelante, también puedes usar este wireframe durante el desarrollo:

• Prototipo: Para convertir el wireframe en un prototipo, solo tienes que introducir la sintaxis de Power Query (M) adecuada para especificar datos simulados en la(s) partición(es) de la tabla. Pueden ser tablas estáticas sencillas de 5 a 25 filas, solo para demostrar la funcionalidad y validar DAX.
• Modelo de desarrollo: Para convertir el wireframe en un modelo funcional, solo tienes que sustituir las particiones por otras que especifiquen la conexión a tu Data source. Si estás usando un objeto de Data source explícito (p. ej., para AAS/SSAS), también tienes que añadir ese objeto. Asegúrate de que el esquema de la tabla coincida con la tabla en la base de datos.

En conclusión

Recopilar los requisitos adecuados es fundamental en cualquier proyecto de datos y BI, para asegurarte de que llegas al resultado deseado. Al crear un modelo semántico, esto implica definir claramente el problema/pregunta de negocio que se quiere abordar y traducir de forma eficaz los requisitos de negocio recopilados a requisitos técnicos.

Una buena forma de hacerlo es responder a un conjunto de preguntas clave sobre tu modelo y luego crear un wireframe del modelo para representar el diseño previsto. Tabular Editor puede ser una buena herramienta para crear un wireframe del modelo, ya que además puedes aprovechar este trabajo más adelante si necesitas un prototipo o una prueba de concepto. Además, también puedes convertir este wireframe en un modelo totalmente funcional en unos pocos pasos sencillos.

3 comentarios sobre “Recopilar requisitos para modelos semánticos”

1. Pingback: Conceptos básicos de DAX en un modelo semántico – Blog de Tabular Editor

2. Pingback: Validar relaciones del modelo semántico – Blog de Tabular Editor

3. Pingback: Preparar tus datos para un modelo semántico – Blog de Tabular Editor