For at dokumentationen kan vedligeholdes og bruges i vores daglige arbejde, skal den have en veldefineret struktur og et klart formål. Denne side beskriver dokumentationens formål og struktur. Dette skal ses som en guide til hvordan man dokumenterer dashboards, kuber og databaser.
Alle ændringer som laves i vores dashboards, CHRU_HRKube og views, samt i de tabeller som kuben bygger på skal dokumenteres. Dette gælder både når man tilføjer nye temaer og når man ændrer på allerede eksisterende. Vi dokumenterer vores arbejde følgende steder:
Dashboards og de tilhørende infobokse skal give et overblik over hvad der vises på en given figur, samt hvilke measures den bygger på og hvilke filtre der er blevet brugt på figuren/siden. Når man bygger dashboardet kommer alt dette naturligt med.
I koden indsætter man korte kommentarer som beskriver hvad bestemte linjer eller dele af koden gør. Beskriv som udgangspunkt hvad koden gør (f.eks. “Tæl antal ansatte”) , ikke hvordan den gør det (dette beskriver koden ofte fint selv). Ved særligt komplekse udtryk kan en mere beskrivende tekst dog være nødvendig. De mere tekniske forklaringer skal så vidt muligt inkluderes som kommentarer i koden, og ikke på wiki-siden eller andre steder. Kommentarer i koden giver et bedre overblik og gør det lettere at genbruge dele af koden på et senere tidspunkt. Man kommenterer normalt koden samtidigt med at man skriver den.
Alle measures, tabeller og kolonner skal have en kort beskrivelse. Denne “description” kan tilføjes i Tabluar Editor og bliver en del af den semantiske model. Dette betyder at man kan se beskrivelserne når man fx arbejder i Power BI. Beskrivelserne bliver også automatisk tilgængelige på vores wiki-side, hvor de er med til at give et overblik over kuben. Beskrivelsen skal som udgangspunkt være kort, og den skal slutte med “[værdi a, værdi b, …]“ som angiver et par eksempler på de værdier kolonnen eller measuret returnerer. Man skriver normalt descriptions ind samtidigt med at man definerer measures, tabeller og kolonner i kuben.
Her kan man skrive spørgsmål eller ændringsforslag ind. Dette sikrer dels at ændringsforslag ikke bliver glemt eller går tabt, samt at det ræsonnement som ligger til grund for beslutninger vedr. dashboards, kuben og databasen bliver gemt. Ofte giver det god mening at konvertere et ændringsforslag til et Issue, da dette bringer flere funktionaliteter med sig. Bl.a. er det muligt at kommentere på Issues og knytte “Pull requests” op på et Issue. På denne måde får man hele historikken med, og kan let se det ræsonnement som ligger til grund for ændringer i kuben, views og wiki-siden. OBS: vær opmærksom på at Issues der oprettes i offentlige repositories som fx dokumentation vil være offentligt tilgængelige.
Alle ændringer i CHRU_HRKube i udvikling og produktion skal ske gennem GitHub. Dette er med til at sikre at vi har et sikkert og stabilt miljø, hvor flere kan arbejde samtidigt. Alle views som har skema-navnet “chru_cube“ og dermed ligger til grund for vores CHRU_HRKube skal også versionsstyres via. GitHub. Man kan læse mere om dette under versionsstyring. Versionsstyringen skal ske sideløbende med at man skriver sin kode.
Wiki-siden samler al vores dokumentation og giver et overblik over vores miljøer og arbejdsgange. Alle ændringer i vores dashboards, kuber og datamodel kræver at man tjekker wiki-siden så den ikke bliver uddateret. Wiki-siden indeholder også beskrivelse af vores arbejdsprocesser samt de værktøjer som vi benytter. Dette gælder dels brug at GitHub, wiki-siden, dokumentering og versionsstyring, men også hvordan man udvikler og arbejder med dashboards, kuber, views og tabeller. Dette er med til at sikre vi har en konsistent måde at arbejde på i alt fra navngivning af kolonner til opsætning af bogmærker i Power BI. Denne dokumentation skrives og opdateres løbende.
De følgende afsnit beskriver hvordan dokumentationen af dashboards, measures og tabeller i kuben er bygget op. Man kan tage udgangspunkt i disse når man skal dokumentere et tema.
Hvert tema dokumenteres på sin egen side. Dokumentationen skal indeholde nogle korte afsnit med en beskrivelse af vigtige overvejelser og tanker man har gjort sig da man lavede temaet. Fx hvis der er truffet nogle principielle beslutninger om afgræsninger eller opgørelsesmetoder. Dette sikrer vidensdeling men kræver ikke meget vedligeholdelse. Når man opdaterer et dashboard gemmer man også BI-filen på L-drevet i mappen Versionsstyring af dashboards. På denne måde kan vi genskabe bogmærker og filer, hvis noget bliver overskrevet eller slettet.
Alle measures er beskrevet i kuben via. descriptions. Denne metadata vises i et Excel-ark for hvert tema og indeholder følgende oplysninger:
Alle tabeller og kolonner er beskrevet i kuben via. descriptions. Denne metadata vises i et Excel-ark for hvert tema og indeholder følgende oplysninger:
[*] Ikke påbegyndt,
[†] Udarbejdes,
[§] Valideres