¿Qué es el modelado de datos? Introducción para analistas de negocios

¿Qué es el modelado de datos?

Como analistas de negocios , a menudo nos involucramos con el modelado de datos de alguna forma. Por eso es importante que todos los analistas de negocios tengan algún nivel de comprensión sobre de qué se trata el modelado de datos. Este artículo describe los conceptos clave asociados con el modelado de datos y proporcionará un ejemplo de un modelo de datos para ayudar en una comprensión más profunda.

Primero consideremos la frase “qué es el modelado de datos” profundizando en los elementos básicos, los datos y el modelado. Los datos están a nuestro alrededor, cualquier cosa que desee capturar como información, recuperar para su uso posterior o consultar en una conversación es un tipo de datos. Cada sistema en esta tierra depende de datos de alguna descripción. Puede registrar datos personales de un empleado en una base de datos de la empresa o información de transacciones generada como resultado de una transacción de ventas. Todo esto son ejemplos de datos.

Datos versus información

Otro aspecto importante de la terminología a tener en cuenta: el término “información” se describe como “datos con un significado”. Entonces, cuando un científico espacial podría interpretar conjuntos matemáticos de datos y considerar que como “datos con significado, es decir, información”, otras personas siempre podrían simplemente llamar al conjunto matemático de datos, un tipo de datos (porque para la mayoría de las personas no tiene un significado específico distinto de ser datos matemáticos).

Con el modelado de datos, se trata de determinar qué datos queremos capturar para un propósito específico y luego organizarlos de manera lógica. También queremos que los conjuntos de datos lógicos se relacionen entre sí de alguna manera porque juntos los datos trabajan juntos para producir información significativa.

¿Qué es el modelado de datos? Entidades o conceptos

que es el modelado de datos

Consideremos este simple ejemplo. A un empleado de una empresa se le paga mensualmente por un puesto de trabajo en particular que desempeña. La empresa quiere encontrar una manera de capturar toda la información relacionada con el empleado, su salario y detalles de pago. La empresa necesita una base de datos para capturar todos estos datos.

Que es el modelado de datos – Entidades / Conceptos

Para modelar los datos que necesitan, el Business Analyst definirá en primer lugar las diferentes “cosas” lógicas o entidades / conceptos sobre los que desea capturar datos. Las entidades pueden ser personas, lugares, productos o cualquier cosa que sea tangible de alguna manera.

Para describir con más detalle ‘qué es el modelado de datos’, considere estas entidades (a veces denominadas conceptos) para el ejemplo proporcionado:

  • Empleado (la “cosa” en este caso es la persona o empleado)
  • Rol de trabajo (la “cosa” en este caso es el rol de trabajo en la estructura organizativa)
  • Paquete de salario (la “cosa” en este caso es el contrato del empleado que estipula el paquete de salario)
  • Detalles de pago (la “cosa” en este caso es la cuenta bancaria del empleado)

¿Qué es el modelado de datos? Atributos

Una vez que haya identificado los conceptos o entidades para los que le gustaría capturar datos, los siguientes pasos son qué desea capturar específicamente para cada entidad en términos de atributos. Si tomamos uno de nuestros ejemplos de entidades de antes, veamos qué atributos nos gustaría capturar:

Empleado = Los atributos pueden incluir: ( Nombre, línea de dirección 1, línea de dirección 2, fecha de nacimiento, ciudad, país, número de teléfono )

Concepto avanzado: un punto importante a tener en cuenta en este punto es que siempre debe capturar información sobre una entidad que esté directamente relacionada con esa entidad. Esto se debe a que con el modelado de datos nuestro objetivo es no duplicar ningún atributo en una tabla de base de datos que lógicamente podría haber sido capturado contra su propia entidad.

¿Qué es el modelado de datos? Relaciones

Ahora que ha identificado las entidades y los atributos, es hora de considerar cómo se relaciona cada entidad entre sí. Las relaciones entre entidades son las relaciones significativas entre sí. Por ejemplo: en nuestro escenario, la entidad Empleado y la Entidad de rol de trabajo tienen una relación directa del Empleado que realiza el rol de trabajo. El rol de trabajo lo desempeña el empleado.

Una vez que haya identificado las relaciones significativas entre estas entidades, podrá definir la cardinalidad o multiplicidad de la relación. Aquí es donde evalúa el número de relaciones permitidas o necesarias entre las entidades. En el ejemplo tenemos: Cada empleado debe realizar un solo rol de trabajo. (La cardinalidad entre el empleado y el puesto de trabajo es 1: 1). Sin embargo, cada Rol de trabajo puede ser realizado por 1 a muchos Empleados (por lo que la cardinalidad entre Rol de trabajo y Empleado es de 1 a muchos).

Que es el modelado de datos – metadatos

Finalmente, el último paso al realizar el modelado de datos es definir los metadatos. Los metadatos son datos que describen datos. Los ejemplos de metadatos incluyen información de uso sobre sus datos. Por ejemplo, si se agregó un registro en su base de datos recién creada, los metadatos describirían cuándo se agregó el registro, por qué usuario y tal vez una bandera para confirmar que está libre de errores.

Entonces, ahora que ha leído sobre los conceptos básicos de lo que es el modelado de datos, como analista de negocios debería poder interpretar y comprender los conceptos fundamentales cuando se enfrenta a un modelo de datos.

Texto original en inglés http://business-analysis-excellence.com/what-is-data-modeling/

Certified Scrum Professional® -ScrumMaster

Esta es el tercer nivel de certificación Scrum Master por ScrumAlliance…y ya lo tengo!!!

En mi caso he elegido hacer el programa con https://www.superheroes.academy/ . Una de las cosas buenas que tiene la formacion online es que puedes realizar un programa que se imparta en cualquier parte del mundo, ellos se encuentran en Canada.

Este programa (al igual que el Advance-Certified Scrum Master, que también lo cursé con ellos) tiene la particularidad que no es el típico formato de dos días de 8 horas de curso cada día, sino que consta de 10 sesiones semanales de hora y media cada una; con los correspondientes homeworks pre y post session que hacen de este programa, algo diferente a los del formado habitual.

Las sesiones fueron lideradas por Brock Argue y Erkan Kadir, a quienes agradezco públicamente su profesionalismo y tiempo.

ISO/IEC 29110: Calidad de software para las PYMEs

Gracias a la amable invitación de la Profesora María Angélica Pérez de Ovalles[1] he podido asistir en la Conferencia sobre ISO/IEC 29110 y el Aseguramiento de la Calidad del Software (SQA) dictada con el Profesor Claude Laporte[2]. La misma la pueden ver en este enlace.

ISO/IEC 29110 es un estándar dirigido a PYMES, especialmente para aquellas integradas hasta por un máximo de 25 personas que se concentra en dos procesos (si, solo dos): gestión del proyecto y gestión del desarrollo del software.

La ISO/IEC 29110 se basa en la norma MoProSoft. La propuesta desde MoProSoft fue ofrecer sus procesos de la categoría de operación como perfil básico, la categoría de gerencia como perfil intermedio y la categoría de alta dirección como perfil avanzado.

CMMI tiene el inconveniente en que es muy pesada para una pequeña empresa, Imagina una desarrolladora de 7 personas, quien se va a poner a cumplir con todos los artefactos de la CMMI? De allí la necesidad que cubre la ISO/IEC 29110. Otro beneficio de esta norma es que otorga a las organizaciones una acreditación reconocida para poder venderse en mercados fuera de su país.

Volviendo a la conferencia, me llamó mucho la atención una afirmación del Profesor Laporte. Según su criterio, las universidades tanto en Latinoamérica como en Canadá tienen el problema de solo enseñar en las carreras de software los aspectos técnicos, dejando de lado la gestión del proceso y la calidad del software.

Revisando por internet, como no podía ser de otra manera, hay mucha material para revisar y empaparse de esta norma. Dejo al final algunos enlaces.

https://es.wikipedia.org/wiki/ISO/IEC_29110

https://iso.statuspage.io/#iso:std:iso-iec:tr:29110:-1:ed-2:v1:es


[1] María Angélica Pérez de Ovalles es profesora del LISI- Laboratorio de Investigación en Sistemas de Información de la Universidad Simón Bolívar de Venezuela.

[2] Claude Y. Laporte es profesor de la École de Technologie Supérieure de Canada

Certified Scrum Product Owner

 

 

EL Product Owner (PO) es el responsable de maximizar el retorno de la inversión que significa construir el producto, es decir, maximizar el valor del producto haciendo el mejor uso posible del tiempo.

Sus tareas principales son: asegurar la visibilidad del product backlog y priorizarlo, tomar decisiones estratégicas de creación del producto en cuanto a su contenido y funcionalidad, dar las indicaciones tal que el producto construido sea el más cercano a las expectativas del mercado.

Voy a listar los puntos más importantes que vivos en estos dos días de curso Product Owner, el cual finalizamos ayer, sin profundizar mucho en ellos:

Comenzamos como no podía ser de otra forma con un resumen de lo que es SCRUM y de lo que no es, para luego pasar a las labores de un PO.

Todas las herramientas que vivos en el curso se dirigen al objetivo final de generar un producto backlog. Estas herramientas fueron: el Lean Canvas, la visión del producto, el elevator pich, la construcción de user personas, la construcción de hipótesis, el Story map, las historias de usuario, la Definition of Ready (DoR) entre otras. La herramienta digital para desarrollarlos fue Mural.

Las siguientes líneas resumen muchas ideas que extraje del curso:

·        El PO debe ser UNA sola persona.

·      Para decir que un Product Backlog Item (PBI) este “Ready” debe cumplir con ser INVEST: Independiente, Negociable, Valorable por el negocio, Estimable, Pequeño y Testeable.

·        A mayor incertidumbre menor debe ser la longitud de los sprints.

·      La finalidad del Product Discovery es buscar la construcción del producto correcto y la finalidad del Prodfuct Delivery es asegurar el construirlo correctamente.

· Se debe tratar de involucrar a la mayor cantidad de eactores en la construcción de la visión del producto.

 

Así pues, resulta que ayer terminamos el curso que nos acredita como Certified Scrum Product Owner por Scrum Alliance. Opté por realizarlo con Martin Alaimo  – martinalaimo.com y creo que fue una buena elección.

Empiricism, the act of making decisions based on what is

Very interesting blog

Ken Schwaber's Blog: Telling It Like It Is

Empiricism is the act of making decisions based on what is. Scrum is an empirical process, sometimes described as “the art of the possible.” By this, I mean that we do the best we can with what we have.

A Product Owner plans a release based on all current information. He or she lays out the goals, the features and capabilities that will deliver those goals, and the probable cost and date of delivery. From that point on, the Product Owner’s job is to assess what is possible given the Team’s capabilities, and to make the best decisions to reach the desired goal. Given the nature of technology, markets, requirements, and people, trade-offs are made. Sometimes the goal cannot be reached for a reasonable price. Sometimes the goal will be reached, but in a way different from what the Product Owner initially intended. This is empiricism in action.

The Team…

Ver la entrada original 320 palabras más

Squad: Lo que le debemos a Spotify

La primera vez que escuché la palabra “escuad” me pregunté que era eso, entendí perfectamente por el contexto pero nunca había escuchado referirse a un equipo scrum con esa palabra. Así que unas horas mas tarde me puse a investigar.

En el 2008 Spotify ya trabajaba con Scrum, no sé si comenzaron en ese año o antes, lo  cierto es que con el pasar del tiempo fueron creciendo el número de equipos scrum y con ese crecimiento se les comenzaron a presentar problemas de organización, lo que ahora se da por llamar “problemas de escalado”, por lo cual comenzaron a obviar algunas prácticas Scrum, pues decidieron que la agilidad era más importante que Scrum, dicho de otra manera, que los principios agiles están por encima de cualquier implementación especifica.  

Y en este punto es que comienza el cambio de nombres, por ejemplo, el Scrum Master pasó a llamarse Agile Coach, reflejando el cambio de paradigma de ser un maestro del proceso a un líder servicial. Otro nombre que cambió fue el de Scrum Team al ser sustituido por Squad.

Siguiendo las reglas Scrum, un squad es un equipo pequeño (no más de ocho personas), autoorganizado y multifuncional. Además en Spotify, un Squad es un equipo responsable no solo del desarrollo del producto sino también de las actividades aledañas como el  despliegue y el mantenimiento. Cada Squad tiene una misión a largo plazo, más allá de la construcción de su producto, que bien puede ser una visión organizacional o metas a mediano plazo de la unidad de negocio o departamento donde se encuentre.

Físicamente, los miembros del Squad trabajan en un mismo sitio que además es cercano a otro lugar donde se realizan las reuniones, y como mencioné al principio para ellos es más importantes ser ágiles que ser scrum. Por ello se pueden encontrar escuadrones que utilizan sprints de Scrum y otros que utilizan Kanban, algunos que miden su velocidad y otros que no, algunos utilizan users stories y otros no.

Cuando hay algún artefacto o herramienta que es utilizada por un número suficiente de Squads, la resistencia se va disminuyendo y espontáneamente se estandariza esa práctica, no hay ningún gerente o directivo imponiéndola.

Todo el sistema Spotify se divide en cientos de aplicaciones que interactúan mediante interfaces y protocolos de comunicación y cada Squad se encarga técnicamente de varias de estas aplicaciones. Internamente, se trabaja con código abierto, esto es, que cualquier persona de cualquier Squad puede modificar el código que “pertenece” a otro Squad pidiéndole eso sí que revise los cambios para su aprobación. La política de revisión de cambios es de revisión por pares.

Teniendo tantos squads por allí, algún tipo de estructura habría que haber, y efectivamente la hay. Los Squads se agrupan en lo que llaman, una tribe (tribu), pero de esto les cuento en una próxima oportunidad.

SCRUM como yo lo veo

SCRUM es un marco de trabajo cuya finalidad es aplicar los cuatro valores del manifiesto ágil:

  1. Individuos e interacciones sobre procesos y herramientas.
  2. Software funcionando sobre documentación extensiva.
  3. Colaboración con el cliente sobre negociación contractual.
  4. Respuesta ante el cambio sobre seguir un plan.

Derivado de esto, SCRUM asume la incertidumbre como parte del proceso de desarrollo de software.

SCRUM como yo lo veo, se basa en una idea simple pero eficaz: Comprobar cada cierto tiempo lo que se va realizando y así detectar defectos rápidamente. En caso que no se consigan defectos se pasa a buscar mejoras del proceso.

Esto hace de SCRUM un sistema ideal para afrontar problemas complejos, donde los requerimientos son cambiantes y/o ambiguos, debido a que el corto tiempo entre las entregas, hace que el equipo tenga una especie de “tensión” para entregar cada vez un producto de valor incrementado.

Lo descrito no es más que ir aprendiendo y mejorando sobre la marcha. En el desarrollo de software, el proceso que más se ajusta a este enfoque es el proceso iterativo-incremental, esto significa que al terminar cada iteración tendremos un “producto mínimo viable” al cual se le irá añadiendo funcionalidades por muy pequeñas que sean. Una iteración en SCRUM recibe el nombre de SPRINT.

Concluyendo; SCRUM funciona estableciendo una lista de funcionalidades que el software a desarrollar debe cumplir y estableciendo tiempos de entrega de entre 2 y 4 semanas. Las claves son: Entregar poco pero funcional, adaptarse a los cambios en los requerimientos, detección temprana de errores para su impacto sea el menor posible y encontrar su pronta solución y revisión continua del proceso.  

La certificación ScrumMaster ¿Cómo renovarla?

Esta pregunta me la hicieron hace algunos días al enterarse que yo había renovado mi certificación Scrum Master. Así pues, comienzo esta web respondiendola para todos aquellos interesados.

Al ingresar en el sitio web de https://www.scrumalliance.org/ para proceder a la renovación me dí cuenta que me faltaban SEUs para poder renovar, sucede que además de los $100 que cuesta dicha renovación es necesario tener 20 SEUs.

¿Qué es un SEU?: Son las siglas de Scrum Education Units. Scrum Alliance quiere que sus miembros certificados se mantengas en constante aprendizaje, que se mantengan “activos”  de allí que sus certificaciones tengan una vigencia de dos años.

Cada certificación obliga a una cantidad específica de SEUs y de dinero, como podemos ver en la siguiente imagen.

Existen muchas maneras de conseguir SEUS:

  1. Lea libros, blogs y  artículos  sobre cualquier práctica, principio o marco ágil. 
  2. Contribuya a un grupo de usuarios local ágil o Scrum. 
  3. Participar en jordanas de aprendizajes ágil en su lugar de trabajo.
  4. Ir a los eventos de seminarios web en vivo o ver seminarios web pregrabados  .
  5. Demuestre el aprendizaje de otra forma creativa. 
  6. Ver los videos gratuitos de aprendizaje en línea de Scrum Foundations.
  7. Inscribirse y participar en el  programa online de coaching.
  8. Asistir a un evento ágil o Scrum  .  

Todas estas maneras de adquirir SEUs pueden ser gratuitas o de pago.

También existe otra manera de renovas una certificacion de Scrum Alliance, que es adquiriendo otra superior. En mi caso particular, si hubiese obtino la certificación A-CSM, la CSM se hubiese renovado automaticamente.

Y así es como se renuevan las certificaciones de Scrum Alliance.

Crea tu sitio web con WordPress.com
Empieza ahora