Klik voor meer informatie over auteur Wayne Yaddow.
In Deel 1 en Deel 2 van deze serie hebben we beschreven hoe datawarehousing (DW) en business intelligence (BI) -projecten voor veel organisaties een hoge prioriteit hebben. Projectsponsors streven naar meer en betere datagestuurde beslissingen en acties in hun hele onderneming; ze zijn van plan hun gebruikersbestand voor BI, analyse en gegevensdetectie uit te breiden, zodat gebruikers weloverwogen beslissingen kunnen nemen.
Deze reeks te vermijden fouten richt zich op het helpen van organisaties bij het omzeilen van datakwaliteitsproblemen die zich voordoen bij DW-projecten. De hier aangeboden tips zullen helpen om tevredenheid te verzekeren wanneer DW-teams nieuwe functies en mogelijkheden plannen en implementeren.
Hieronder volgen meer van de fouten die door verschillende beoefenaars zijn gemaakt.
Afhankelijk van BI-rapporttests om defecten in het datawarehouse te ontdekken
DW-projecten zijn vol uitdagingen – van de kwaliteit van de gegevens in het magazijn tot de afgeleide waarden in BI-rapporten. Als het niet snel wordt aangepakt, kan een slechte datakwaliteit (vooral binnen het datawarehouse) complete projecten tot stilstand brengen.
Data opslagplaats voldoet vaak niet aan de verwachtingen door het ontbreken van Data kwaliteit. Studies hebben aangetoond dat de datakwaliteit het vaakst afneemt bij het verplaatsen van gegevens van bronnen naar verschillende gebieden van het datawarehouse en datakluizen. Een grondige beoordeling van de gegevenskwaliteit moet worden uitgevoerd wanneer het laden van de bron begint en bij elke stap waarin gegevens worden opgeschoond, getransformeerd, geaggregeerd en geïntegreerd in het datawarehouse.
Wachten tot BI- of analytische rapporten beschikbaar zijn om de meeste projecttests voor datakwaliteit uit te voeren (datatransformaties, dubbele data, ontbrekende data, null-waarden, toepassing van bedrijfsregels, enz.), Kan resulteren in langdurige en complexe probleemoplossing voor defecten die kunnen zijn geïdentificeerd en eerder tegen lagere kosten gerepareerd.
Hieronder volgen vijf DW-gegevensproblemen – zoals geïdentificeerd in meerdere onderzoeken – met de grootste waarschijnlijkheid dat ze optreden en een direct effect hebben op het succes van een project. Merk op dat enkele van deze risico’s samenhangen met defecten in BI-rapporten.
1. Fouten in brongegevenskwaliteit – van interne en externe bronnen
2. Toewijzing van bron-naar-doelgegevens en schemafouten
3. Datafouten als gevolg van meerdere ETL-processen
4. Query-prestatieproblemen ETL-processen
5. Gegevens opschonen en transformatiefouten
Bij het testen van BI- en analytische rapporten gaat het erom ervoor te zorgen dat gegevens correct worden benaderd vanuit het datawarehouse, dat de rapportlay-outs zijn zoals gedefinieerd, dat aan de bruikbaarheidseisen wordt voldaan, dat drill-downs en aggregaties van rapporten correct werken. Het BI-rapporttestproces zou moeten niet zijn wanneer u ontdekt dat er gegevens ontbreken of gedupliceerd zijn in de datamarts of dat er andere defecten bestaan die ontdekt hadden moeten worden tijdens ETL-verificatie.
Het niet naar behoren uitvoeren van DW-prestatie-, belasting- en stresstests
De meeste projectmanagers zouden functionele en datakwaliteitstests niet vertragen tijdens de ontwikkeling van hun DW-project. Te veel DW-projecten testen echter prestaties, belasting, stress, beveiliging en herstel in de latere stadia van de ontwikkelingslevenscyclus – soms zonder voldoende tijd te gunnen om eventuele belangrijke problemen op te lossen.
Onaanvaardbare prestaties kunnen een belangrijke oorzaak zijn van het annuleren van DW-projecten. De DW-prestaties moeten worden onderzocht voor zowel de reactietijden van de query als de ETL-tijden (bijvoorbeeld elk uur, dagelijks). De reactietijden van zoekopdrachten kunnen enkele minuten bedragen wanneer miljoenen of meer rijen worden gebruikt voor berekeningen. Op enkele uitzonderingen na is dit onaanvaardbaar. Dergelijke prestaties hebben een negatieve invloed op de beschikbaarheid van de DW voor de gebruikers.
DW-prestaties zijn essentieel afhankelijk van de databaseprestaties. Old-school ontwikkelingsmethodologieën voorbehouden prestatietests voor laat in de ontwikkelingscyclus; het was gewoon niet mogelijk om de prestaties eerder te testen, omdat er pas heel laat in het spel geen representatief werkend systeem was.
Enkele best practices voor het testen van agile databaseprestaties zijn:
- Een prestatietestplan ontwikkelen: Tests moeten worden geïdentificeerd voor zowel individuele transacties als algemene gebruiksgevallen. Testbelastingen moeten worden geconfigureerd om de doorvoersnelheid te testen onder verschillende belastingen, variërend van niet-actieve tot breekpunt-stresstests. Gelijktijdige tests moeten de doelgegevens variëren om cacheproblemen op zowel het applicatieframework als het databaseniveau te identificeren.
- Het verstrekken van Voldoende tijd en budget: voor het inzetten van een geschikte omgeving voor prestatietesten. Het prestatietestplatform moet van productieschaal zijn of een kwantificeerbare fractie daarvan.
- Planning voor realistisch geschaalde gegevens: Dit kan een productiemomentopname zijn (voor bestaande systemen) of het kan nodig zijn om realistisch geschaalde synthetische gegevens te zijn voor nieuwe of snelgroeiende systemen.
Het niet leveren van adequate meetresultaten met testresultaten aan het projectteam
Voor testteams is een van de belangrijkste resultaten informatie die de voortgang van het testwerk en de teststatus levert. Teststatistieken zijn essentieel om de huidige testinspanning te begrijpen en om verbeteringen te overwegen die nodig zijn bij zowel ontwikkeling als testen.
Tegenwoordig worden veel DW-tests uitgevoerd door bedrijfsanalisten, data-analisten en ontwikkelaars. Als gevolg hiervan zijn bruikbare teststatistieken voor tal van DW-projecten mogelijk niet beschikbaar. Leden van veel QA-teams hebben de deelname aan DW-testen verminderd, gedeeltelijk vanwege een gebrek aan gegevensgerelateerde technische vaardigheden – vaardigheden die nodig zijn voor het testen van DW-projecten.
Er is altijd behoefte aan metrieken met betrekking tot kwaliteitsborging. Uw projectteam kan alleen verbeteren en controleren wat er wordt gemeten bij het plannen, ontwikkelen, uitvoeren en voltooien van tests die worden gerapporteerd met behulp van metrische gegevens die voortgang en succes kwantificeren.
QA-metrieken moeten zodanig zijn ontworpen dat ze kunnen worden vertrouwd en gebruikt om bruikbare projectbeslissingen te nemen. De metrische gegevens die tijdens DW-tests zijn ontwikkeld, bieden twee belangrijke voordelen voor project- en bedrijfsmanagers: inzicht in 1) de volwassenheid en gereedheid voor vrijgave voor productie en in 2) de kwaliteit van het softwareproduct in ontwikkeling. Testrapporten maken een effectief beheer van het softwareontwikkelingsproces mogelijk door een duidelijke meting van de kwaliteit en volledigheid van het DW-project.
Metrics voor elk van de DW primaire kwaliteitscategorieën – databasemanagementkwaliteit, datamodel / schemakwaliteit, datawarehouse-datakwaliteit – zouden idealiter het volgende moeten omvatten: testcase pass / fail metrics, productiviteitsstatistieken (dwz welke geplande tests werden uitgevoerd of niet) , defectfrequentie-dichtheid door DW-component, defecten ontdekt door prioriteit / ernst en vereisten die niet worden gedekt door tests.
Het QA-team moet teststatistieken leveren aan belanghebbenden die op overtuigende wijze de voortgang van het testen aantonen. En QA-statistieken helpen belanghebbenden van het project om go en no-go-projectbeslissingen te ontwikkelen.
