Quel contenu figure dans un Design Document - Résumé

Quel est le résumé des principaux points de contenu d’un Design Document ?

Tout au long de cette série, de nombreux points ont été abordés dans chacune des grandes sections du design document Power BI, et avec ce numéro, j’aimerais lister mes principaux points personnels pour chaque section. Alors, c’est parti :

Général

Le design document est un document « vivant » (il sera mis à jour tout au long des périodes de conception, de test et d’utilisation en production), donc incrémentez la version à chaque itération. Utilisez un format et un emplacement de stockage courants dans votre organisation, accessibles à toutes les parties prenantes (afin qu’elles puissent facilement [et constamment] le retrouver et le consulter), et disposant d’un contrôle de version.

Périmètre (Scope)

Soyez précis sur tous les éléments du périmètre, et listez-les en trois sections : ceux qui seront inclus, ceux qui seront exclus, et ceux qui seront reportés à une itération ultérieure.

[!NOTE]
Note de conception : vous pouvez réduire la dérive du périmètre (« scope creep ») en étant impitoyable à la fois sur la priorité et sur le périmètre (excluez tout ce que vous pouvez, reportez tout ce que vous pouvez). N’incluez que les éléments essentiels et de haute priorité.

« Si tout est prioritaire, alors rien n’est prioritaire »

Workflow

Incluez un organigramme de workflow simple (avec des couloirs/« swim lanes ») pour la source des données (c’est-à-dire depuis les systèmes opérationnels), l’emplacement d’accès intermédiaire aux données (par exemple, SharePoint, etc.), et le Power BI Service (avec des couloirs pour les tables de staging, les tables transformées, et le modèle et les rapports dans le workspace Power BI).

Problèmes (Issues)

Listez chaque problème rencontré pendant le développement, en incluant l’historique complet des décisions pour chaque niveau de statut (par exemple, NOUVEAU, CRITIQUE, NOTE, EN COURS, RÉSOLU, REPORTÉ, etc.). Ajoutez, ne modifiez pas.

Règles métier (Business Rules)

Documentez les règles métier afin que les développeurs, les testeurs et les utilisateurs mesurent la même chose ; cela permettra d’éviter les « erreurs non forcées ». Utilisez un statut pour enregistrer toute activité ainsi que le niveau de statut d’approbation correspondant (par exemple, NOUVEAU, BROUILLON, DISCUSSION, RÉVISÉ, APPROUVÉ (par qui), etc.)

Données (Data)

Décrivez intégralement tous les environnements qui seront utilisés dans le projet (par exemple, DEV, TEST, PROD, etc.).

[!NOTE]
« Tout le monde a un environnement TEST ; certains ont la chance d’avoir aussi un environnement PROD »

Listez chaque source de données, décrivez ses identifiants d’accès, et notez son statut (par exemple, EXISTANTE, NOUVELLE, EN DÉVELOPPEMENT, APPROUVÉE (par qui), VÉRIFIÉE (par qui), etc.) ainsi que la date.

[!NOTE]
Note de conception : utilisez des comptes système/principaux de service, pas des comptes personnels.

Réduisez le volume de données (lignes x colonnes) autant que possible pour chaque rapport.

[!NOTE]
« Réduisez le volume de données autant que possible en agrégeant le plus en amont possible »

« Il n’y a aucun bénéfice à transférer des données que vous n’allez pas utiliser »

Rapports (Reports)

Incluez un en-tête (avec le titre et la date du dernier rafraîchissement des données) et un pied de page (avec l’ID du rapport et la version [mise à jour à chaque itération]) sur chaque page.

[!NOTE]
Note de conception : utilisez un thème standard, des filtres cohérents, et une navigation familière (votre première option devrait être la navigation intégrée fournie par les Power BI Apps).

Validation

Consignez les tests d’acceptation manuels dans un tableau (ID, groupe, nom, notes, priorité, résultats attendus, tolérance/variance autorisée, étapes de préparation, étapes de procédure, résultats réels, étapes de nettoyage, date, réalisé par, et statut).

[!NOTE]
Note de conception : fournissez les tests d’acceptation aux développeurs le plus tôt possible pendant la période de développement, chaque cas décrivant un scénario et le comportement attendu, y compris les chemins normaux, alternatifs et d’exception le cas échéant.

Les tests d’acceptation devraient être réalisés par des personnes différentes des développeurs.

Les tests ne sont pas « terminés » lorsqu’un rapport est déployé en environnement de production ; il convient plutôt de mener une surveillance régulière et continue pour confirmer que le rapport fonctionne comme prévu (par exemple, rafraîchissement des données, fonctionnalité, accès, etc.).

Déploiement (Deployment)

Suivez une procédure écrite pour chaque déploiement, faites-la signer après chaque réalisation, et intégrez toutes les « leçons apprises » pour rendre les futurs déploiements plus fluides et plus faciles.

[!NOTE]
Note de conception : utilisez des paramètres de source de données et déployez le même fichier PBIX vers chaque environnement ; ajustez les paramètres dans les pipelines de déploiement ou dans le Power BI Service selon les besoins.

Utilisez les pipelines de déploiement comme premier choix (si la licence le permet) pour des déploiements itératifs et reproductibles. N’utilisez le déploiement manuel qu’en cas de nécessité.

Un déploiement n’est pas « terminé » simplement parce qu’il s’est achevé sans erreur. Utilisez des tests de fumée (« smoke testing ») pour confirmer l’accès et la fonctionnalité de base.

Modèle (Model)

Extrayez les données telles quelles dans des tables de staging clairement nommées. Référencez, fusionnez, ou ajoutez ces tables de staging avant d’appliquer les transformations nécessaires pour créer les tables du modèle.

Utilisez les fonctions DAX INFO VIEW pour extraire le modèle (tables, colonnes, relations, mesures) tel qu’implémenté et regrouper le tout dans des tables de documentation.

[!NOTE]
Note de conception : utilisez une table de dimension [Dates] unique, standard et conforme aux bonnes pratiques (et marquez-la comme telle). Voici un excellent exemple Power Query/M par l’experte Enterprise DNA Melissa de Korte :

https://forum.enterprisedna.co/t/extended-date-table-power-query-m-function/6390

[!NOTE]
Note de conception : utilisez une table de support [Dernier rafraîchissement]. Voici un excellent exemple Power Query/M par l’experte Enterprise DNA Melissa de Korte :

https://forum.enterprisedna.co/t/adding-a-last-refresh-date-to-your-report/6485

Ressources (Resources)

Publications LinkedIn

Les publications LinkedIn couvrant le design document sont listées ci-dessous :
1. Général et Périmètre
2. Workflow, Problèmes, et Règles métier
3. Données
4. Rapports
5. Validation
6. Déploiement
7. Modèle
8. Résumé

Exemples

Des fragments de documents exemples couvrant des sections spécifiques sont disponibles dans le dépôt GitHub :

1, Design Document - Sample Fragment 01 - General and Scope
2. Design Document - Sample Fragment 02 - Workflow, Issues, and Business Rules
3. Design Document - Sample Fragment 03 - Data
4. Design Document - Sample Fragment 04 - Reports
5a. Design Document - Sample Fragment 05 - Validation
5b. Design Document - Sample Validation Spreadsheet
6. Design Document - Sample Fragment 06 - Deployment
7a. Design Document - Sample Fragment 07 - Model
7b. Design Document - Sample Power BI File