Voorkom deze fouten in uw datawarehouse en BI-projecten: deel 2

Klik voor meer informatie over auteur Wayne Yaddow.

In Deel 1 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 fouten moet worden vermeden richt zich op het helpen van organisaties om kwaliteitsproblemen te omzeilen die te vaak voorkomen bij DW-projecten. De hier aangeboden tips zullen helpen om tevredenheid te verzekeren wanneer DW-teams nieuwe functies en mogelijkheden plannen en implementeren.

Tekortkomingen in beoordelingen van DW / BI-projectvereisten en technische ontwerpen

Shift-links
kwaliteitsverzekering is een benadering van DW-ontwikkeling waarbij kwaliteitsborging vroeg en vaak in de levenscyclus wordt uitgevoerd – links van zijn gebruikelijke positie in het algehele projectplan. “Shift naar links”Verwijst naar dynamische gegevenskwaliteitsverificaties en statische tests: het uitvoeren van beoordelingen, inspecties en eenheid- en integratietests. Veel DW-projecten zijn echter nog niet begonnen dit potentieel belangrijke proces te omarmen.

Het verificatieproces naar links verschuiven gedurende de levenscyclus van het project is een agile praktijk die een middel levert voor verificaties met (of parallel aan) ontwerp- en ontwikkelingsactiviteiten. Dat wil zeggen dat ontwikkelingsteams en QA-teams samenwerken om tests te plannen, beheren en uitvoeren die de feedback van problemen naar het bedrijf en ontwikkelaars versnellen.

Wanneer kwaliteitszorgopdrachten eerder in de projectlevenscyclus worden geoefend, nemen DW-architecten, bedrijfs- en gegevensanalisten, en ETL- en BI-rapportprogrammeurs “test” -rollen op zich om problemen te identificeren. Indien vroegtijdig geïmplementeerd, kunnen validaties om zich te concentreren op bedrijfsregels en beveiliging – en zelfs acceptatietests – een tastbaar voordeel zijn voor de kwaliteit en het succes van het project.

Weken of maanden aan het einde van een releasecyclus besteden om problemen op te sporen en op te lossen, is inefficiënt. Een IBM-studie meldde dat “het 100 keer goedkoper is om een ​​defect vroegtijdig te repareren dan nadat het voor productie is vrijgegeven.” Alleen al die berekening zou de meeste teams achter shift-left-testen moeten krijgen.

Een ander doel van shift-left-testen is het oplossen van problemen die in de toekomst kunnen optreden, zelfs tijdens de productie. Wanneer organisaties een shift-left-strategie toepassen, kunnen ze daarom de voortgang testen, analyseren en een oordeel vellen over het systeem, veel beter stukje bij beetje in plaats van allemaal tegelijk.

Het nalaten om testprocessen met best practices te identificeren die gegevenstransformaties en BI-rapporten verifiëren

De meeste tests voor veel (misschien wel de meeste) DW-projecten worden uitgevoerd door SQL-scripts uit te voeren en de resultaten vervolgens in spreadsheets te verzamelen voor verdere analyse.

Die benadering van ETL-tests kan traag en foutgevoelig zijn. Het handmatig uitvoeren van DW-tests zonder speciale procesondersteunde tools om deze tests te ontwerpen en te beheren, kan testautomatisering op korte en lange termijn dwarsbomen.

Herhaald testen is essentieel om een ​​hoog niveau van ETL-gegevenskwaliteit te garanderen. Hoe meer u test, hoe meer bugs u zult ontdekken voordat u live gaat. Het is cruciaal voor bedrijfsinformatie projecten. Wanneer gebruikers de gegevens niet kunnen vertrouwen, komt de acceptatie van BI- of analyseoplossingen in gevaar. Het implementeren van geavanceerde ETL-testprocessen ondersteunt frequente regressie- en rooktesten.

De beslissing om geavanceerde processen en tools voor ETL-tests te implementeren, hangt af van een budget dat uitgaven ondersteunt om aan geavanceerde testvereisten te voldoen. Testtools die intern zijn gebouwd en onderhouden, zijn waarschijnlijk beter dan helemaal geen testtools. Veel ETL-toolproviders bieden testoplossingen die rechtstreeks zijn gericht op de ETL-tool (bijv. Informatica’s Data Validation Option – DVO).

Enkele van de vele opmerkelijke testprocessen zijn:

  • Verificaties van bron-tot-doel gegevenstest:
    Recordaantallen, dubbele gegevenscontroles, gegevenstransformatietests, regressietesten, rooktesten
  • Processen voor het testen van belasting: Tests die op realistische wijze een geschikt aantal gebruikers simuleren om de applicatie-infrastructuur te valideren op prestaties, betrouwbaarheid en schaalbaarheid

Inschakeling van externe en interne testers met onvoldoende DW-testvaardigheden

De impuls om DW-projectkosten te verlagen is vaak intens, vooral in late projectfasen. Een veel voorkomende fout is het delegeren van tal van testverantwoordelijkheden aan resources met beperkte zakelijke en gegevenstestvaardigheden. Van DW-projectleiders en andere hands-on testers wordt vaak verwacht dat ze uitgebreide ervaring hebben met het ontwerpen, plannen en uitvoeren van database- en datawarehouse testgevallen.

In de afgelopen jaren hebben DW-projecten een trend meegemaakt naar bedrijfsanalisten, ETL-ontwikkelaars, uitbestede testers – en zelfs zakelijke gebruikers – voor het plannen en uitvoeren van een groot deel van het QA-proces. Dit kan riskant zijn. De volgende zijn enkele van de vaardigheden die vaak vereist zijn voor DW-testen:

  • Diepgaande kennis van het bedrijf, technische vereisten van DW, bedrijfsprocessen en zakelijke terminologie
  • Het vermogen om strategieën, testplannen en testcases te ontwikkelen die specifiek zijn voor datawarehousing en de bedrijfsactiviteiten
  • Vaardigheden voor het implementeren van code in databases
  • Vaardigheden voor het oplossen van problemen met ETL-sessies en workflows
  • Een goed begrip van DW en databaseconcepten
  • Geavanceerde vaardigheden met SQL-queries en scripting

Datawarehousing-projecten kunnen om vele redenen mislukken: slechte gegevensarchitectuur, inconsistente gegevensdefinities, gebrek aan functies om gegevens uit verschillende gegevensbronnen te combineren, ontbrekende of onnauwkeurige gegevenswaarden, inconsistent gebruik van gegevensvelden, onaanvaardbare queryprestaties, enzovoort.

De meeste cruciale projectrisico’s en mislukkingen worden verminderd wanneer goed opgeleide en ervaren testers voortdurende ondersteuning bieden vanaf de vroegste ontwikkelingsfasen tot en met de voltooiing van het project.

Table of Contents

Vragen voor onze consultants?

Twijfel niet en neem direct contact met ons op met uw vraagstuk.