Ein­lei­tung

Die Microstra­tegy Intel­li­gence Platt­form (MSTR) besteht aus diver­sen Kom­po­nen­ten, die in einem Unter­neh­men im Bereich Busi­ness Intel­li­gence und Ana­ly­tics ein­ge­setzt wer­den kön­nen. Haupt­kom­po­nente der Platt­form ist der MSTR Intel­li­gence Ser­ver, wel­cher die Durch­füh­rung von Ana­ly­sen jeg­li­cher Art ermög­licht. Diese kön­nen mit Hilfe von ver­schie­de­nen Cli­ents wie z. B. MSTR Web, MSTR Deve­lo­per, MSTR Work­sta­tion, MSTR Mobile, MSTR Office etc. ange­stos­sen und auf unter­schied­li­che Art und Weise dar­ge­stellt wer­den. All diese Kom­po­nen­ten unter­lie­gen einer stän­di­gen Wei­ter­ent­wick­lung kos­me­ti­scher wie auch fun­da­men­ta­ler Natur durch den Her­stel­ler. Dar­über hin­aus wer­den jähr­lich neue Fea­tures ein­ge­führt. Gross ange­prie­sen wurde für die Ver­sion 2020 unter ande­rem die neue Funk­tion MSTR Hyper­in­tel­li­gence Cards. Die­ses Fea­ture ermög­licht dem Kun­den das Anzei­gen einer Karte mit ana­ly­ti­schen Daten, indem der Kunde mit dem Maus­zei­ger per Hoo­ver Effekt über vor­her defi­nierte Enti­tä­ten in ope­ra­ti­ven Sys­te­men gleitet.

Ein MSTR Upgrade bringt, im Gegen­satz zu App-Updates auf dem eige­nen Smart­phone, immer sehr viel Auf­wand mit sich. Für ein erfolg­rei­ches Upgrade ist ein Zusam­men­spiel von ver­schie­de­nen Rol­len zwin­gend not­wen­dig. Es wer­den sowohl Ent­wick­ler oder Admi­nis­tra­to­ren, wel­che die Upgrades der Kom­po­nen­ten durch­füh­ren als auch Tes­ter fach­li­cher Natur und Tes­ter sei­tens der IT bean­sprucht. und Zudem sind koor­di­na­tive Rol­len­be­set­zun­gen wie etwa Pro­jekt­lei­ter unverzichtbar.

Um ein MSTR Upgrade erfolg­reich zu gestal­ten, sollte es unter­schied­li­che Pha­sen durch­lau­fen. Zunächst bedarf es einer Kon­zept- und Vor­be­rei­tungs­phase, in der die Pla­nung und erste Kon­zepte ent­ste­hen. Anschlies­send folgt eine Rea­li­sie­rungs­phase, wel­che die Umset­zung der Kon­zepte beinhal­tet. Schwer­punkte der letz­ten Phase sind das Tes­ten und das Pro­to­kol­lie­ren der Test­ergeb­nisse. Das Ziel, «Erfolg­rei­che Durch­füh­rung des Upgrades», ist dann erreicht, wenn die Berei­che Per­for­mance, Sta­bi­li­tät, Inhalt (gene­rierte SQL’s) und Dar­stel­lung hin­rei­chend getes­tet wer­den konn­ten und zufrie­den­stel­lende Resul­tate erzielt wur­den. Um die­ses Ziel zu errei­chen wer­den beim Tes­ten ent­we­der Werte vor und nach dem Upgrade gegen­über­ge­stellt (A‑B-Ver­gleich) oder aber Test­ergeb­nisse mit Refe­renz­wer­ten verglichen.

In den nach­fol­gen­den Kapi­teln wer­den die ein­zel­nen Pha­sen des Upgrades MSTR 2020 aus Sicht des Arbeits­tak­tes Test­ing detail­liert betrachtet.

Kon­zept und Vorbereitung

Ein Pro­jekt wie das MSTR Upgrade 2020 kann mit­hilfe von Pro­jekt­ma­nage­ment­me­tho­den wie HERMES 5 in Teilpakete/Module (Pro­jekt­füh­rung, Tes­ten, Ein­füh­rungs­or­ga­ni­sa­tion etc.) auf­ge­teilt wer­den, für die jeweils ein Ver­ant­wort­li­cher defi­niert wird. Inner­halb die­ser Module sind in der Kon­zept­phase diverse Doku­mente zu erstel­len. Bei­spiels­weise ist im Modul Tes­ten ein Test­kon­zept zu defi­nie­ren, wel­ches ver­schie­dene Aspekte zum Tes­ten ent­hält. Am Bei­spiel des Test­kon­zepts wird nach­fol­gend dar­ge­legt, wel­che Aspekte bei der Erstel­lung von Doku­men­ten in der Phase Kon­zept und Vor­be­rei­tung zu beach­ten sind. 

Im Test­kon­zept müs­sen zunächst die zu errei­chen­den Test­ziele auf­ge­führt wer­den. Anschlies­send ist die Frage nach rele­van­ten Test­ob­jek­ten zu beant­wor­ten. Es müs­sen Test­ar­ten wie auch Test­pha­sen, deren Ver­ant­wort­lich­kei­ten sowie Test­ab­schluss- und Test­abbruch­kri­te­rien beschrie­ben wer­den. Dar­über hin­aus sind eine Test­or­ga­ni­sa­tion sowie deren Rol­len zu defi­nie­ren. Es muss ein Feh­ler-Manage­ment-Pro­zess vor­lie­gen, damit sicher­ge­stellt ist, dass der Feed­back­loop funk­tio­niert, soll­ten die Test­re­sul­tate nicht dem erwar­te­ten Ergeb­nis entsprechen. 

Dar­über hin­aus sind Feh­ler­klas­si­fi­zie­run­gen und Prio­ri­sie­run­gen zu defi­nie­ren. Für jede Umge­bung, die aktua­li­siert wer­den soll, muss defi­niert sein, wel­che Tests kon­kret pro­zes­siert wer­den sol­len und es muss eine Rei­hen­folge für die Umge­bun­gen fest­ge­legt wer­den. Zu guter Letzt sind Tools zu benen­nen, mit­hilfe derer die vor­hin genann­ten Auf­ga­ben durch­ge­führt wer­den kön­nen. MSTR lie­fert hier den haus­ei­ge­nen Inte­grity-Mana­ger, mit des­sen Hilfe viele der defi­nier­ten Tests, wie Ver­glei­che von SQL’s oder Dar­stel­lun­gen vor und nach dem Upgrade, durch­ge­führt wer­den kön­nen. Mit dem Inte­grity-Mana­ger las­sen sich zudem auch Resul­tate pro­to­kol­lie­ren und archi­vie­ren. Trotz­dem kann bei der Pro­to­kol­lie­rung der Tests, vor allem in Anbe­tracht kol­la­bo­ra­ti­ver Arbei­ten wie der Feed­back­schleife dem Feh­ler-Manage­ment-Pro­zess oder der Bereit­stel­lung von stan­dar­di­sier­ten Test­schrit­ten an die Fach­tes­ter, auf Tools wie das Appli­ca­tion-Life-Cycle-Manage­ment (ALM) Qua­lity Cen­ter (QC) nicht ver­zich­tet werden.

Wie an die­sem Bei­spiel gezeigt wurde, müs­sen viele Dinge berück­sich­tigt wer­den, bevor die Durch­füh­rung des eigent­li­chen Upgrades in Angriff genom­men wer­den kann.

Durch­füh­rung des Upgrades

Im Rah­men der Phase Kon­zept und Vor­be­rei­tung wird u. a. defi­niert, in wel­cher Rei­hen­folge ein­zelne Umge­bun­gen aktua­li­siert wer­den sol­len, falls mehre vor­han­den sind. In der Regel soll­ten ein­zel­nen Umge­bun­gen wie Inte­gra­tion, Ent­wick­lung, Test, Pro­duk­tion unab­hän­gig von­ein­an­der aktua­li­siert wer­den. Bei einem der­ar­ti­gen Vor­ge­hen ent­ste­hen Loops, in denen pro Umge­bung die Upgrades und anschlies­send alle Tests durch­ge­führt wer­den. Bei der Defi­ni­tion der Rei­hen­folge wird emp­foh­len mit den am wenigs­ten genutz­ten Umge­bun­gen zu begin­nen, zum Bei­spiel Integrationsumgebungen.

Eine wei­tere zen­trale Anfor­de­rung, wel­che im Rah­men der Kon­zept­phase defi­niert wird, ist häu­fig, dass das Upgrade nicht – oder nur gering­fü­gig – den Betrieb ein­schrän­ken darf. Es stellt sich somit kon­se­quen­ter Weise die fol­gende Frage: Wie lange dau­ert es, bis die Pro­duk­ti­ons­um­ge­bung aktua­li­siert und hin­rei­chend getes­tet wurde, sodass sie den Usern wie­der zur Ver­fü­gung gestellt wer­den kann? Gelingt es nicht die anfal­len­den Pro­zesse (Upgrade und Tes­ten) auf ein akzep­ta­bles Mini­mum zu beschrän­ken, so muss für die Zeit, in der die Pro­duk­ti­ons­um­ge­bung nicht zur Ver­fü­gung steht, eine Über­gangs­lö­sung zur Ver­fü­gung ste­hen. Bei­spiels­weise kann die Test­um­ge­bung mit pro­duk­ti­ven Daten von den Usern genutzt wer­den. Dies bedingt aller­dings eine umfang­rei­che Vor­be­rei­tung. Es muss sicher­ge­stellt wer­den, dass Pro­duk­ti­ons­um­ge­bung und Test­um­ge­bung vor dem Upgrade syn­chro­ni­siert wer­den und zwar in Bezug auf die Daten in der Daten­bank als auch die Meta­da­ten von MicroStra­tegy. Sobald dies der Fall ist kann zunächst die Test­um­ge­bung aktua­li­siert wer­den. Nach erfolg­rei­chem Upgrade grei­fen die Benut­zer über­gangs­weise auf die aktua­li­sierte Test­um­ge­bung zu und die Pro­duk­ti­ons­um­ge­bung kann auf den neus­ten Stand gebracht wer­den. Sobald auch die­ses Upgrade erfolg­reich war, wer­den beide Umge­bun­gen erneut syn­chro­ni­siert. Nach der Syn­chro­ni­sa­tion dür­fen die Benut­zer wie­der wie gewohnt auf die pro­duk­tive Umge­bung zugreifen.

Vor dem eigent­li­chen Upgrade müs­sen auf jedem Ser­ver Back­ups der Server‑, der Pro­jekt­kon­fi­gu­ra­tio­nen und der Meta­da­ten erstellt wer­den. Um die Per­for­mance zwi­schen den bei­den Ver­sio­nen ver­glei­chen und die Inte­gri­tät der Daten sicher­stel­len zu kön­nen, wer­den vor dem Upgrade zusätz­li­che Inte­grity-Mana­ger-Tests und Sta­bi­li­täts­tests durch­ge­führt. Für die neue MSTR-Ver­sion müs­sen aus­ser­dem ggf. vor­han­dene Steue­rungs­skripte ange­passt wer­den, wobei u. a. auch die neuen Funk­tio­nen inte­griert werden.

Die Kom­ple­xi­tät der eigent­li­chen Instal­la­tion hält sich in Gren­zen, da diese mit Hilfe des von MSTR bereit­ge­stell­ten GUIs funk­tio­niert. Der kom­ple­xere Teil ent­fällt auf die anschlies­sende Kon­fi­gu­ra­tion der instal­lier­ten Kom­po­nen­ten. Neben der Aktua­li­sie­rung der ser­ver­sei­ti­gen Steu­er­skripte und der in der odbc.ini gespei­cher­ten Daten­bank­ver­bin­dun­gen müs­sen auch die Meta­da­ten aktua­li­siert und neue Funk­tio­nen ange­bun­den werden.

Tes­ten und Protokollieren

Da keine Objekte ent­wi­ckelt wer­den, fal­len in sol­chen Life­cy­cle-Pro­jek­ten die Ent­wick­ler­tests weg. Somit blei­ben noch die Integrations‑, die Fach- und die (Vor-) Abnah­me­tests. Sofern die Bewirt­schaf­tung der ange­bun­de­nen Daten­ban­ken nicht auch aktua­li­siert wer­den, also nur die MicroStra­tegy Plat­form erneu­ert wird, kann auf das Tes­ten der Daten eben­falls ver­zich­tet wer­den. Im Kon­trast dazu ist es aber unab­ding­bar die gene­rier­ten SQLs der MSTR-SQL-Engine zu ver­glei­chen. Hier kön­nen bei­spiels­weise Unter­schiede in der Rei­hen­folge von Attri­bu­ten ent­ste­hen, die aber kei­nen Ein­fluss auf die prä­sen­tierte Rei­hen­folge der Attri­bute im Report hat und daher als Abwei­chun­gen doku­men­tiert sind, diese jedoch nicht ange­gan­gen werden.

Sol­che Tests kön­nen mit­hilfe des Inte­grity-Mana­gers durch­ge­führt wer­den und gehö­ren zu den Inte­gra­ti­ons­tests. Auch bei der Dar­stel­lung kann der Inte­grity-Mana­ger einen Vor­her-Nach­her-Ver­gleich durch­füh­ren. Der Punkt kann aber auch im Rah­men der Fach­tests durch das Busi­ness getes­tet wer­den indem immer zwei Umge­bun­gen neben­ein­an­der ver­gli­chen und Abwei­chun­gen pro­to­kol­liert wer­den. Die Per­for­mance- und Sta­bi­li­täts­tests kön­nen lei­der nicht mit­hilfe des Inte­grity-Mana­gers durch­ge­führt wer­den, da die­ser für sol­che Auf­ga­ben nicht kon­zi­piert wurde. Hier­für stellt aber MSTR Java-Tools zur Ver­fü­gung. Diese Per­for­mance- und Sta­bi­li­täts­tests sind dar­auf aus­ge­rich­tet die Web- und Intel­li­gence-Ser­ver von MSTR auf Herz und Nie­ren zu prü­fen. Dabei kann man zum Bei­spiel Para­me­ter wie Anzahl an Cube-based-Reports oder Anzahl gleich­zei­tig kon­kur­rie­ren­der Benut­zer einstellen.

Zusam­men­fas­sung

Wenn auch nur ein Bruch­teil der Arbei­ten, die bei einem MSTR Upgrade not­wen­dig sind, in die­sem Blog beschrie­ben wur­den, konnte trotz­dem auf­ge­zeigt wer­den, dass ein sol­ches Upgrade in Punkto Auf­wand wie auch Kom­ple­xi­tät nicht zu unter­schät­zen ist und genü­gend Res­sour­cen ein­ge­plant wer­den müssen.