Sie befin­den sich hier:Start­sei­te/Blog/Auto­ma­ti­sier­te Vali­die­rung einer Continuous-Integration-Toolkette

Automatisierte Validierung einer Continuous-Integration-Toolkette

Lese­zeit: 7 Minu­ten
success story fresenius socialshare

Eine Erfolgsgeschichte in Zusammenarbeit mit FRESENIUS MEDICAL CARE

Die Aufgabe

Seit 1979 hat Fre­se­ni­us Medi­cal Care die medi­zi­ni­sche Erfolgs­ge­schich­te der Behand­lung chro­ni­scher Nie­ren­er­kran­kun­gen wesent­lich mit­ge­schrie­ben. Die kon­ti­nu­ier­li­che Wei­ter­ent­wick­lung der Pro­duk­te stellt gera­de die Software­entwicklung vor die Her­aus­for­de­rung, qua­li­ta­tiv guten Code in immer kür­ze­ren Release-Zyklen zu erzeugen.

Dies ist ohne das Kon­zept der kon­ti­nu­ier­li­chen Inte­gra­ti­on kaum mehr vor­stell­bar. „Con­ti­nuous Inte­gra­ti­on“ (CI) bedeu­tet, dass die zu ent­wi­ckeln­de Soft­ware mög­lichst häu­fig kom­pi­liert, gebaut und im Anschluss dar­an geprüft wird. So erhal­ten die Ent­wick­ler schnell Feed­back über durch­ge­führ­te Änderungen.

Die erfor­der­li­che Werk­zeug­ket­te ent­hält neben der eigent­li­chen Build-Umge­bung eine Rei­he von Soft­ware-Werk­zeu­gen, die unter­schied­li­che Prü­fun­gen durch­füh­ren. Dazu gehö­ren Tools zur sta­ti­schen und dyna­mi­schen Code-Ana­ly­se sowie das Frame­work für die auto­ma­ti­sier­ten Unit-Tests. Für den Ein­satz im regu­lier­ten Umfeld muss die­se Werk­zeug­ket­te vali­diert werden.

Das Vorgehen

Für die Vali­die­rung beauf­trag­te Fre­se­ni­us Medi­cal Care die sepp.med gmbh. sepp.med führ­te zunächst eine Bestands­auf­nah­me der bestehen­den Werk­zeu­ge durch. Die­se „Inven­tur“ ergab eine Lis­te von zwan­zig Werk­zeu­gen, die je nach Pro­jekt zum Ein­satz kom­men kön­nen. Des Wei­te­ren klär­te sepp.med in einer Rei­he von Sta­ke­hol­der-Inter­views die geplan­te Ver­wen­dung der CI-Tool­ket­te. So wur­de u.a. ermit­telt, wel­che Pro­gram­mier­spra­chen rele­vant sind, wel­che Werk­zeu­ge ver­wen­det wer­den und wie die Anwen­dungs­fäl­le aus­se­hen. Die­se wur­den gra­phisch als UML-Dia­gramm doku­men­tiert und in Akti­vi­täts­dia­gram­men wei­ter detailliert.

Par­al­lel dazu führ­te Fre­se­ni­us Medi­cal Care eine Risi­ko­ana­ly­se (FMEA) durch und iden­ti­fi­zier­te eine Rei­he von Maß­nah­men. Die Risi­ko­ana­ly­se bil­de­te zusam­men mit den in den Inter­views ermit­tel­ten Work­flows die Grund­la­ge für die Anfor­de­rungs­spe­zi­fi­ka­ti­on der Toolkette.

Beson­ders im Fokus stand die Vali­die­rung der MISRA C++ Regeln und der von Fre­se­ni­us spe­zi­fi­zier­ten Aus­nah­men, die nicht zu Feh­ler­mel­dun­gen füh­ren dür­fen. Für die zu vali­die­ren­den Com­pi­ler wur­den ver­schie­de­ne Sze­na­ri­en geprüft, dar­un­ter die Kon­fi­gu­ra­ti­on, der Abbruch im Feh­ler­fall, mög­li­che Warning Levels und natür­lich das Erzeu­gen der Bina­ries. Dar­über hin­aus spe­zi­fi­zier­te sepp.med im Vali­die­rungs­plan Work­flow-Tests, die sich an den ermit­tel­ten Abläu­fen orientierten.

Bereits zu Beginn des Pro­jek­tes war klar, dass ein Teil der Tests auto­ma­ti­siert wer­den soll­te. Ers­tens wäre es zeit­rau­bend und feh­lerträch­tig gewe­sen, die ver­schie­de­nen Test­da­ten „per Hand“ zuzu­wei­sen und die Log-Datei­en im wört­li­chen Sin­ne „lesend“ aus­zu­wer­ten. Zwei­tens war die Men­ge der Test­da­ten hän­disch nicht hand­hab­bar, da allein meh­re­re hun­dert MIS­RA-Regeln veri­fi­ziert wer­den muss­ten. Drit­tens war abseh­bar, dass eine grö­ße­re Anzahl der Tests erneut durch­ge­führt wer­den muss. sepp.med eva­lu­ier­te ver­schie­de­ne Alter­na­ti­ven. Die Wahl fiel schließ­lich auf das Test­au­to­ma­ti­sie­rungs-Frame­work Spock, das Test­durch­füh­rungs-Werk­zeug grad­le und die Pro­gram­mier­spra­che Groo­vy. Die zen­tra­le Steu­er­ein­heit bil­det der Jenkins-Ser­ver, über wel­chen das Test­pro­jekt aus­ge­checkt und kon­fi­gu­riert wird.

Die Anfor­de­run­gen, Test­fäl­le und die Test­durch­füh­rung der manu­el­len und auto­ma­ti­sier­ten Tests durch sepp.med wur­den im ALM-Werk­zeug Pola­ri­on doku­men­tiert. Zum Abschluss erstell­te sepp.med einen Validierungsbericht.

Die Erfolgsfaktoren

Die Dia­ly­se­ge­rä­te von Fre­se­ni­us Medi­cal Care ent­hal­ten zuneh­mend kom­ple­xe­re Soft­ware. Um die­se qua­li­ta­tiv hoch­wer­tig in immer kür­ze­ren Release-Zyklen bereit­zu­stel­len, setzt Fre­se­ni­us Medi­cal Care auf das Kon­zept der Con­ti­nuous Inte­gra­ti­on (kurz: CI). Die dafür erfor­der­li­che Tool­ket­te wur­de durch sepp.med validiert.

„Die Vali­die­rung durch sepp.med war für uns der opti­ma­le Weg, unse­re Werk­zeug­ket­te abzusichern.“
Horst Bach­mann, Direc­tor Soft­ware, Pro­ce­du­res, Elec­tro­ni­cal Engineering

Das Ergebnis

Für die sta­ti­sche Code­ana­ly­se wur­den Test­da­ten ver­wen­det, die vom Her­stel­ler des Tools zur Ver­fü­gung gestellt wur­den. Daher war eigent­lich zu erwar­ten, dass der Test der MIS­RA-Regeln pro­blem­los lau­fen würde.

Es stell­te sich jedoch her­aus, dass eini­ge MIS­RA-Regel­ver­stö­ße nicht kor­rekt detek­tiert wur­den. Damit zeig­te sich uner­war­tet deut­lich, wie wich­tig die Tool-Vali­die­rung tat­säch­lich ist.

Über die Zusammenarbeit

Drei Fak­to­ren tru­gen wesent­lich zum Erfolg des Pro­jek­tes bei:

Die Anforderungsermittlung

Zu Beginn wur­den die Tool­ket­te, die anzu­wen­den­den Pro­zess­vor­ga­ben und Richt­li­ni­en sowie die genau­en Anfor­de­run­gen geklärt. Die­se Zeit war gut inves­tiert. Anfor­de­run­gen an das zu vali­die­ren­de Sys­tem, die vor­her nicht bewusst waren, wur­den ermit­telt – und somit auch imple­men­tiert. Ande­re Anfor­de­run­gen wur­den wie­der ver­wor­fen, weil sie sich als nicht sinn­voll herausstellten.

Die Modellierung

Die erstell­ten Use­Ca­se- und Akti­vi­täts­dia­gram­me waren einer­seits sehr hilf­reich, die ermit­tel­ten Ergeb­nis­se zu kom­mu­ni­zie­ren, ande­rer­seits dien­ten sie zur Fest­le­gung des Vali­die­rungs­um­fangs und damit auch zur Abgren­zung von ande­ren Validierungsprojekten.

Die Automatisierung

Das Test­au­to­ma­ti­sie­rungs­kon­zept konn­te mit gro­ßem Erfolg in einem Fol­ge­pro­jekt über­nom­men wer­den. Grund­la­ge dafür war die tex­tu­el­le Spe­zi­fi­ka­ti­on des erwar­te­ten Sys­tem­ver­hal­tens, wie sie im Beha­vi­or-Dri­ven Deve­lo­p­ment (BDD) üblich ist und durch Spock unter­stützt wird. Damit redu­zier­te sich z.B. die Prü­fung der zahl­rei­chen MIS­RA-Regeln auf das simp­le, leicht ver­ständ­li­che Schema:

  • Given [Vor­be­din­gung]
  • Expect [Ver­let­zung der MIS­RA-Regel wird entdeckt]
  • Whe­re [MIS­RA-Regel]

Mit­tels die­ses BDD-Sche­mas kön­nen die erstell­ten Basis­skrip­te jeder­zeit neu kom­bi­niert und somit neue Test­fäl­le mit gerin­gem Auf­wand spe­zi­fi­ziert und imple­men­tiert werden.

Fazit

Obwohl – bzw. gera­de weil – zunächst kei­ne Frei­ga­be der CI-Tool­ket­te erfolg­te, betrach­ten Fre­se­ni­us Medi­cal Care und sepp.med die Vali­die­rung als Erfolg. Zum einen ist es gelun­gen, Feh­ler durch blin­des Ver­trau­en in Tools zu ver­mei­den. Zum ande­ren wur­de die Grund­la­ge für wei­te­re auto­ma­ti­sier­te Vali­die­run­gen gelegt. Die auto­ma­ti­sier­ten Tests wur­den seit Abschluss des ers­ten Durch­laufs bereits mehr­fach wie­der­holt. Inzwi­schen ist geplant, auch die Work­flow-Tests zu auto­ma­ti­sie­ren. Auf die­se Wei­se wird es mög­lich, jeden neu­en CI-Ser­ver vor sei­nem Ein­satz inner­halb eines hal­ben Tages voll­stän­dig zu prüfen.

Fin­den Sie Ant­wor­ten auf alle Fra­gen, die Sie sich bei der Ent­wick­lung von Soft­ware als Medi­zin­pro­dukt regel­mä­ßig stel­len: www.software-als-medizinprodukt.de

Kommentare und Feedback gerne via Social Media:

Blei­ben Sie auf dem Lau­fen­den – mit dem monat­li­chen sepp.med Newsletter: