Dienst Informatietechnologie, Bibliotheek & Educatie Informatievoorziening & Automatisering MISUT-QA Project : MISUT QA Versie 1.0 Kenmerk : ITBE/davi/ Versie Datum Aangeleverd Bijgewerkt Beschrijving 1.0 21-11-2006 John Davina Initiële versie
Inhoudsopgave INHOUDSOPGAVE 2 1 INEIDING 3 2 DOESTEING 3 3 UNIVERSE 4 3.1 Documenteren van de universe-eigenschappen 4 3.2 Documenteren van de classes 4 3.3 Documenteren van de Objecten 5 3.4 Datum, een bijzonder object 6 4 WERKWIJZE 7 4.1 Procesbeheersing 7 4.2 Voorbeeld tijdbalk fasering van een MISUT-traject 7 4.3 Kwaliteitsbeheersing en acceptatiecriteria 8 4.4 Processchema MISUT-aktiviteit 9 BIJAGE A 10 2
1 Inleiding De Misut-database wordt (is) een datawarehouse die gevuld wordt met extracties uit een aantal onderliggende databases en daarmee de mogelijkheid creëert om in rapportages dwarsverbanden te leggen en om de historische ontwikkeling van gegevens zichtbaar te kunnen maken. Inmiddels zijn er een al enkele universes gebouwd op de Misut-database. Deze universes, de basis waarop één of meer, maar in een aantal gevallen grote aantallen (deel)rapportages zijn gebouwd, geven de (gevorderde) BO gebruikers vaak niet voldoende duidelijkheid over de eigenschappen van de classes en objecten (tabellen en data). Bovendien is de onderhoudbaarheid matig. Dit is te wijten aan: - zeer gebrekkige documentatie in de beschikbare universes (omdat we hieraan tot op dit moment te weinig aandacht hebben besteed) - onduidelijke naamgeving van classes en objecten in de universe (denk hierbij aan het gebruik homoniemen (bijv. het object jaar komt voor in meerdere classes en soms ook nog met een verschillende betekenis). De naamgeving vanuit de brondata wordt in vele gevallen één op één overgenomen in de universe. Dit creëert de volgende problemen: - misverstanden over de betekenis van classes en objecten met als gevolg een verkeerde interpretatie van de brongegevens dus - rapportages met onjuiste informatie - onvoldoende vertrouwen gebruikers - te verwachten onderhoudsproblemen in de toekomst 2 Doelstelling Het aantal universes en rapportages zal nog fors gaan toenemen. Om aan iedere informatievraag een optimaal en betrouwbaar antwoord te kunnen geven moet de toegankelijkheid tot de universes en daarmee tot classes en objecten verbeterd worden. Bovendien kan de onderlinge samenhang van de universes nog verbeterd worden. Business Objects biedt het EIM Framework aan die de toegangkelijkheid sterk verbeterd en waarborgd. Bovendien bieden ondersteunende BO-tools mogelijkheden om meta-data vast te leggen die in het MISUT-traject zeer waardevol zijn. De Business Objects tools die we momenteel in gebruik hebben bieden hiervoor beperkte mogelijkheden. Specifiek kunnen we daar waar we universes, classes en objecten definieren ook metadata beschrijven. De metadata zegt één op één iets van een class of object en maakt ze specifiek. Deze metadata wordt getoond als een class of object benaderd wordt tijdens het bouwen van een rapport (mbv Business Objects of WebIntelligence) en is tevens onderdeel van de gegenereerde universe-documentatie. Bovendien willen (moeten) we globale ontwerpregels met elkaar afspreken o.a. wat betreft het nesten van classes en het consequent gebruik van dimensie-, detail- en measure-objecten. Wellicht valt er zelfs iets te zeggen over de ordening van classes en objecten. Dit document is een eerste aanzet hiertoe en zal in de loop van de tijd worden uitgebreid met nieuwe afspraken Middels éénduidige regels en afspraken komen tot één standaard voor: - Een uniforme en betekenisvolle naam voor universes, classes en objecten - een uniforme beschrijving (documentatie) van de universes, classes en objecten op het niveau van de gebruiker - Een goede controle op de naleving van de hierna geformuleerde standaarden 3
3 Universe 3.1 Documenteren van de universe-eigenschappen De (lange) naam van de universe is uniek en samengesteld uit drie delen gescheiden door een spatie: o projectnaam o domeinnaam(afkorting OW, OZ, P, F, Fac., Val., Man.) o trefwoord Voorbeeld: MISUT OW inschrijvingen De beschrijving van de universe moet voor de gebruiker (BO en WI InfoView?) duidelijk zijn en informatie verstrekken over het doel en de inhoud van de universe (omschrijving), de brondata (bijv. ISIS) en de frequentie waarmee het ET-proces op de brondata wordt uitgevoerd. Een regeleinde wordt verkregen door op CTR+Enter te drukken (Figuur 1). Figuur 1 3.2 Documenteren van de classes Een class is een verzameling van objecten vergelijkbaar met een folder in de Windows omgeving. Een class herbergt objecten die allen een gezamenlijk doel hebben. Bijvoorbeeld een class studenten bevat alle objecten die op de een of andere manier één op één iets van de student zeggen. In de meeste gevallen geeft een class een voorstelling weer van een (deel)tabel uit de onderliggende brondata (Misut) of van de resultaten van views, zijnde bewerkingen die tijdens het ET-proces plaatsvinden (zelfs vanuit verschillende databases). Ingeval dit niet opgaat dan is het een logische verzameling van bij elkaar horende objecten (vanuit bestaande tabellen/views of objecten die het resultaat zijn van een formule) 4
De naam van de klasse (class) is binnen de universe uniek en samengesteld uit drie delen gescheiden door een spatie: o projectnaam o T (Tabel), V(View) of (logisch) gevolgd door een unieke indicatie (getal) vanuit de MISUT database of uniek binnen de universe o Trefwoord De beschrijving kan door gebruikers in het dialoogvenster worden bekeken. De informatie in dit vak moet aansluiten bij het vocabulair van de gebruikers en relevant zijn voor hun behoeften bij het maken van queries. Hier wordt informatie gegeven over: o de inhoud o het doel o restricties, alias, joins etc. Figuur 2 3.3 Documenteren van de Objecten In de context van Business Objects is een object een universeonderdeel met een naam die voor een kolom of functie in een database staat. Elk object staat voor een entiteit, feit of berekening zoals die in de (zakelijke) omgeving van de eindgebruiker wordt gebruikt. De gebruiker ziet deze objecten en kan deze bij zijn/haar queries voor rapportages gebruiken. Elk object is gekoppeld aan een kolom of functie. Het is uitermate van belang dat de gebruiker de eigenschappen (definitie, herkomst, type, format, key, (voorbeeld van mogelijke) values) kan inzien en op een juiste wijze kan interpreteren. Zie figuur 3. 5
Primair is de naam van het object de indicator voor zijn of haar keuze. Zorg er dus voor dat de objectnaam voorkomt in het zakelijk vocabulair van de eindgebruikers. Deze naam mag afwijken van de werkelijke naam van de kolom waaraan het object in het databaseschema is gekoppeld en is uniek binnen de class. De beschrijving kan door gebruikers in het dialoogvenster, tijdens het queryontwerp worden bekeken. De informatie in dit vak moet aansluiten bij het vocabulair van de gebruikers en relevant zijn voor hun behoeften/keuzes bij het maken van queries. Hier wordt, in een vaste layout, informatie gegeven over: o de begripsbepaling (wat stelt het voor) o Oorspronkelijke naam in de MISUT tabel o Type o Formaat en lengte o Sleutel (uniek of niet uniek) o Mogelijke waarden of voorbeeld van een waarde Figuur 3 3.4 Datum, een bijzonder object Bij de bouw en het gebruik van Business Objects rapporten komen we een groot aantal problemen met datums tegen. Problemen die we op dit moment niet direct kunnen oplossen. M.a.w. hiermee moet altijd bijzonder zorgvuldig worden omgegaan. Daar waar het kan wordt de gebruiker hierop geattendeerd vooral als de datum een (selectie) parameter is. Zie ook Bijlage A. 6
4 Werkwijze De basis voor de documentatie van de universe, classes en objecten is vastgelegd in het functioneel ontwerp voor zover dat in deze fase mogelijk is. Classes en objecten die omwille van optimalisering en performance verbetering (functies) tijdens de bouw van de universe worden toegevoegd moeten eveneens worden gedocumenteerd volgens de hiervoor vermelde regels. Zowel de informatie-analist als de systeemontwikkelaar hebben hierin een belangrijke rol. 4.1 Procesbeheersing Deelprojecten zoals MISUT-OW zijn op te delen in een aantal aktiviteiten (rapporten). Daarnaast bestaat een aktiviteit uit een aantal fases (informatieanalyse, ontwikkeling, acceptatie en productie). Als mijlpalen in het traject worden de opgeleverde producten gezien. De informatieanalist / projectleider (IA/P) rapporteert aan de projectleider MISUT (P-MISUT) over de voortgang en de planning. Indien, om welke reden dan ook, vertraging optreet dient hij of zij dat te melden aan de projectleider MISUT. De projectleider MISUT rapporteert eens per twee weken aan de Technische Werkgroep MISUT. 4.2 Voorbeeld tijdbalk fasering van een MISUT-traject IA gereed > FO, - rapp. aan Projectleider 1 Universe gereed. - rapp. aan P- MISUT - universe naar QMdevelopment 3 Test rapport(en) - rapp. aan P-MISUT - rapporten en universe naar QMacceptatie 5 21 24 26 28 30 32 34 36 weeknummers 2 4 6 ET > DWH MISUT - rapp. aan P-MISUT Rapport(en) gereed. - rapp. aan P- MISUT - rapporten naar QM- development Acceptatietest rapport(en) - rapp. aan P- MISUT - rapporten en universe naar QM- productie 1 Vanuit de domeinbeschrijving maakt de IA/P het functioneel ontwerp (FO) en rapporteert hierover aan de P-MISUT. 2 Indien er een ET-traject bestaat rapporteert de betreffende systeemontwerper (SO) rapporteert aan de IA/P. De IA/P rapporteert aan de P-MISUT. De universe wordt geplaatst in de bedrijfsdocumenten (QM onder development) 3 Als de universe gereed en getest (vzv de test kan worden uitgevoerd) is rapporteert de SO aan de IA/P. De IA/P rapporteert aan de P-MISUT. 4 Bouw rapportages zijn gereed en voor test beschikbaar. De betreffende systeemontwerper (SO) rapporteert aan de IA/P. De IA/P rapporteert aan de P-MISUT. De rapporten worden geplaatst in de bedrijfsdocumenten (QM onder development) 5 De IA/P test samen met de SO de rapporten in combinatie met de universe. Als de testresultaten positief uitvallen worden de universe en de rapportages aan de bedrijfsducumenten toegevoerd (QM onder acceptatie) De IA/P rapporteert hierover ten alle tijde aan de P-MISUT. 6 De acceptatietest wordt uitgevoerd door de eindgebruiker (DUB). Bij een positief uitvallend testresultaat geeft DUB de P-MISUT opdracht de betreffende rapportages en universe in de bedrijfsdocumenten te plaatsen (QM productie) en beschikbaar te stellen aan vooraf bepaalde eindgebruikers. 7
4.3 Kwaliteitsbeheersing en acceptatiecriteria De acceptatiecriteria geven de minima aan waaraan de kwaliteitseigenschappen dienen te voldoen. Acceptatiecreteria worden getest in het testtraject door SO en IA/P. Testobjecten hierin zijn het datawarehouse (DWH), de universes en de rapportages (zie onderstaande tabel). In het ontwikkeltraject zijn 4 testmomenten te onderkennen. Ieder testtraject kent een go of nogo. Nadat een universe of rapport geplaatst is in QM-acceptatie controleert de P- MISUT of de universe volgens de in dit document genoemde afspraken is opgeleverd. Dit geld ook voor de layout van de opgeleverde rapporten. Product 1 Datawarehouse Kwaliteitseigenschap Acceptatie criteria Volledigheid 100 % (1) Juistheid 100 % (1) Tijdigheid 100 % (1) Hoe te testen Vergelijking gegevens uit bronsysteem met geladen gegevens. Afspraken hierover liggen vast in het FO (Gegevenslevering) Wie SO, IA/P en Gebruiker(s) 2 Universes Volledigheid 100 % Juistheid 100 % Geschiktheid 100 % Beveiliging 100 % Vergelijking rapporten op basis van de universe met gegevens of rapportages uit het bronsysteem Conform bronsysteem voor opvragen van gegevens, check per gebruikersgroep SO, IA/P 3 (technisch) Rapporten 4 (acceptatie) Documentatie 100 % Volgens afspraken P-MISUT Bruikbaarheid Performance (2) Inhoud (3) Opmaak (3) Platform onafhankelijk Uitvoering van vooraf gedefinieerde rapporten op de productieomgeving tijdens kantooruren Inhoud gaat om cijfers en de mogelijkheden rapporten aan te passen (parameterisering) Opmaak gaat om het uiterlijk (UTlayout) van de rapporten Rapporten zijn opvraagbaar via een browser (web) SO & IA/ P P-MISUT SO & IA/ P Gebrui kers (DUB) Gebrui kers (DUB) 1. Alle verschillen zijn verklaarbaar en gedocumenteerd 2. Performance, onderscheid eenvoudige, complexe rapporten en rapporten die veel of weinig gebruikt worden (bepalen acceptabele responstijd) 3. Kan m.b.v. een schaalmeter bijv.1 t/m10. (een te lage waardering vereist aanpassing) 8
4.4 Processchema MISUT-aktiviteit FO ET Bouw universe Test DWH ACC? J Test universe 1 ACC J 2 Bouw Rapport Test Rapport J ACC c? 3 Acc test Rapport J ACC? 4 9
Bijlage A Problemen met datum-objecten De problematiek zit hem vooral in de mogelijke wijze van presentatie van de datum en de invloed van de omgeving op de presentatie. Datums zijn doorgaans als datum opgeslagen in een database. Dit houdt in dat de datum in de database als een getal is opgeslagen. Zodra een datum veld uit een database wordt opgehaald beginnen de problemen! In de database wordt tevens aangegeven op welke wijze datums worden opgeslagen. Deze informatie wordt door applicaties gebruikt om de vastgelegde datum te berekenen en deze datum te displayen op de door een gebruiker aan gegeven wijze. Wat kan er zoal mis gaan? 1. Een gebruiker heeft een Engels talige werkplek met als datum formaat US (mmdd-yyyy). Zodra een Nederlandse gebruiker een datum in tikt zal hij of zij doorgaans de datum intikken in UK formaat (dd-mm-jjjj). Stel hij wil gegevens selecteren van de periode 3 april 2005 tot en met 9 juni 2005. Gebruiker tikt in: 9-6-2005>datum> 3-4-2005 volgens het UK formaat worden nu de gegevens verzameld van 4 maart 2005 tot 6 september 2005. 2. De web-server zet de datum op US formaat. In de webbrowser treedt hetzelfde probleem op als hiervoor beschreven op een lokale werkplek. 3. De web applicatie dwingt het UK formaat voor de datum af. Gebruiker die de datum volgens US formaat afhandelt komt in de problemen. 4. Een lijst met waarden (OV) wordt weergegeven in US formaat het rapport gaat uit van UK formaat. Ook hier wordt de maand als dag gebruikt en de dag als maand. Je krijgt in veel gevallen wel een overzicht maar niet met de gegevens die je had verwacht. We zoeken naar manieren en regels om deze problemen te voorkomen. In rapporten afdwingen dat datums in UK formaat worden aangeboden. In rapporten afdwingen dat datums in UK formaat worden verwerkt. Een andere optie is het gebruik van het ISO datum formaat! Dit internationale formaat dat door ISO is gedefinieerd(iso 8601) probeert alle problemen op te lossen door de datum als volgt te definiëren: YYYY-MM-DD YYYY is het jaar [enkel nummers bv 2006] MM is de maand [01 (januari) tot 12 (December)] DD is de dag [01 tot 31] 10