In der Soft­ware Qua­li­ty Assuran­ce wer­den bei der dyna­mi­schen Qua­li­täts­si­che­rung (Soft­ware­tes­ten) ver­schie­de­ne Metho­den ange­wandt, um die Qua­li­tät von Pro­duk­ten und Pro­zes­sen abzu­si­chern. Anhand einer Doku­men­ta­ti­on wer­den die Bestre­bun­gen Ihrer Qua­li­tät test­fä­hig gemacht. Wei­ter­le­sen

Um wir­kungs­vol­le IT-Lösun­gen zu pla­nen und zu kon­zi­pie­ren, ist ein pro­fes­sio­nel­les Pro­jekt­ma­nage­ment unum­gäng­lich. Dabei soll­ten vor allem die Ziel­vor­ga­ben für die spe­zi­fi­sche IT-Lösung klar defi­niert und das Pro­jekt dar­auf auf­bau­end detail­liert kon­zi­piert wer­den. Zudem soll­ten Soft­ware-Pro­jek­te auf­grund ihrer Kom­ple­xi­tät gene­rell in Arbeits­schrit­te auf­ge­teilt wer­den, nach deren Abschluss die jewei­li­gen Ergeb­nis­se ana­ly­siert und für die wei­te­re Kon­zep­ti­on berück­sich­tigt wer­den. Da die­se IT-Ergeb­nis­se in ihren Aus­wir­kun­gen meist schwer abzu­schät­zen sind, soll­ten Sie unbe­dingt auf agi­le Pro­jekt­me­tho­den und die rich­ti­gen Tech­no­lo­gi­en set­zen. Aber auch der Anwen­der der spä­te­ren IT-Lösung soll­te in den Kon­zep­ti­ons­pro­zess mit ein­ge­bun­den wer­den. Da pro­fes­sio­nel­les Pro­jekt­ma­nage­ment zur Pla­nung und Kon­zep­ti­on von IT-Lösun­gen so kom­plex inein­an­der grei­fen, ist es eine logi­sche Fol­ge, dass die Nach­fra­ge danach in Unter­neh­men kon­ti­nu­ier­lich steigt. Eini­ge Kern­punk­te, auf die beim pro­fes­sio­nel­len Pro­jekt­ma­nage­ment zur Pla­nung und Kon­zep­ti­on von IT-Lösun­gen zu ach­ten ist, wer­den im Fol­gen­den dar­ge­stellt.

Von der Wich­tig­keit kla­rer Ziel­de­fi­ni­tio­nen vor Pro­jekt­be­ginn

Bereits die ESI-Stu­die aus dem Jahr 2005 ergab, dass geschei­ter­te IT-Pro­jek­te häu­fig auf feh­len­de oder gar unzu­rei­chen­de Ziel­de­fi­ni­tio­nen zurück­zu­füh­ren sind. Daher soll­ten bereits vor der Pla­nung und Kon­zep­ti­on von IT-Lösun­gen die­se spe­zi­fisch fest­ge­hal­ten, von allen Betei­lig­ten akzep­tiert und zeit­lich ter­mi­niert wor­den sein. Dazu soll­ten ein geziel­tes Pro­jekt erstellt und fest­ge­hal­ten wer­den, wem wel­che Ver­ant­wor­tung dabei zufällt und in wel­cher Zeit die ein­zel­nen Arbeits­schrit­te abzu­schlie­ßen sind.

IT-Pro­jek­te auf­grund ihrer Kom­ple­xi­tät in Ent­wick­lungs­pha­sen auf­tei­len

Da Pro­jek­te, die inner­halb derer IT-Lösun­gen geplant und kon­zi­piert wer­den kom­plex sind, soll­ten die­se in Ent­wick­lungs­pha­sen auf­ge­teilt wer­den. Nach jeder Ent­wick­lungs­pha­se soll­ten die bis­her erreich­ten Ergeb­nis­se aus­gie­big getes­tet und über­prüft wer­den. Die Aus­wer­tung der Ergeb­nis­se soll­te im Fol­gen­den dann auch für die zukünf­ti­gen Ent­wick­lungs­pha­sen berück­sich­tigt, bzw. über­ar­bei­tet wer­den.
Agi­le Pro­jekt­me­tho­den ermög­li­chen es außer­dem, auf die Kom­ple­xi­tät eines IT-Pro­jekts zu reagie­ren, indem zum Bei­spiel im Nach­hin­ein noch Ände­rungs­wün­sche vom Kun­den berück­sich­tigt wer­den kön­nen. Gene­rell ist es dabei rat­sam, dass die Anwen­der der spä­te­ren IT-Lösung in den Pro­jekt­ab­lauf mit ein­be­zo­gen wer­den, um auch hier zu erken­nen, was zwin­gend einer Kor­rek­tur bedarf.

Die ite­ra­ti­ve Ent­wick­lung beschreibt den Ansatz, ein Gesamt­pro­jekt in vie­le klei­ne Pro­jek­te auf­zu­tei­len. Es wer­den in jeder Ite­ra­ti­on alle Pha­sen, also Ana­ly­se, Ent­wurf (Grob- und Fein­de­sign), Imple­men­tie­rung und Test durch­ge­führt. Nach jeder Ite­ra­ti­on soll­te eine Abnah­me mit dem Kun­den erfol­gen, um so die Anfor­de­run­gen und die Qua­li­tät der Soft­ware zu über­prü­fen.

Der Vor­teil hier­bei ist, dass Män­gel bei jedem Ite­ra­ti­ons­schritt besei­tigt wer­den kön­nen und so das Sys­tem stän­dig ver­bes­sert wird – durch Opti­mie­rung bereits bestehen­der Kom­po­nen­ten oder Ergän­zung um wei­te­re.
Neben der kon­ti­nu­ier­li­chen Pro­blem­be­he­bungs­mög­lich­keit bringt das ite­ra­ti­ve Vor­ge­hen bei der Soft­ware­ent­wick­lung auch den Vor­teil, dass in die­sem Ansatz gut auf Ände­run­gen der Anfor­de­run­gen wäh­rend des Pro­jekt­ab­laufs ein­ge­gan­gen wer­den kann. Außer­dem lässt sich so auch das Risi­ko unan­ge­mes­se­ner Funk­tio­na­li­tät und über­hand neh­men­der Kos­ten ein­schrän­ken. Die­se Vor­ge­hens­wei­se ermög­licht es,  tech­nisch oder inhalt­lich sehr ris­kan­te Berei­che eine Soft­ware­pro­jek­tes zuerst anzu­ge­hen.

Aller­dings bringt die mehr­ma­li­ge Durch­füh­rung der Ent­wick­lungs­pha­sen den Nach­teil mit sich, dass das Pro­jekt zeit­lich schwer plan­bar ist, da bei jeder Ite­ra­ti­on Zeit­puf­fer für die Reak­ti­on auf auf­kom­men­de Pro­ble­me ein­kal­ku­liert wer­den müs­sen.

Der Ansatz der ite­ra­ti­ven Ent­wick­lung wird in vie­len Vor­ge­hens­mo­del­len ange­wandt. Eines die­ser Vor­ge­hens­mo­del­le ist das soge­nann­te Spi­ral­mo­dell.

Das Spi­ral­mo­dell nach Boehm ist in fol­gen­de vier Schrit­te auf­ge­teilt:
Im ers­ten Schritt, der Ana­ly­se, wer­den alle wich­ti­gen Infor­ma­tio­nen wie Zie­le, Anfor­de­run­gen, Rah­men­be­din­gun­gen und Lösungs­al­ter­na­ti­ven zusam­men­ge­tra­gen. Die­se wer­den zur Umset­zung frei­ge­ge­ben und im zwei­ten Schritt eva­lu­iert, um Risi­ken zu erken­nen und ent­spre­chen­de Min­de­rungs- bzw. Ver­mei­dungs­stra­te­gi­en zu erar­bei­ten.
Anschlie­ßend wird nun das Vor­ge­hen für die Rea­li­sie­rung fest­ge­legt und durch­ge­führt. Schließ­lich wird in Schritt vier kri­tisch auf die vor­an­ge­gan­gen Schrit­te geschaut und der nächs­te Schlei­fen­durch­lauf geplant.
Im Spi­ral­mo­dell stel­len die vier Qua­dran­ten die Vor­ge­hens­schrit­te dar und eine Linie zeigt den Fort­schritt des Pro­jek­tes, wodurch sich das für die­ses Modell cha­rak­te­ris­ti­sche Spi­ral­mus­ter ergibt. Die Pro­to­ty­pen, die in jedem Schlei­fen­durch­lauf erstellt wer­den, ermög­li­chen, das Sys­tem fort­lau­fend zu prü­fen und wei­ter­zu­ent­wi­ckeln.

Moder­ne Soft­ware-Ent­wick­lung ist eine sehr struk­tu­rier­te und bis ins Detail durch­dach­te Ange­le­gen­heit. Ein Aus­druck die­ser kla­ren Struk­tur sind nicht nur das Las­ten- und Pflich­ten­heft, bei denen detail­liert fest­ge­hal­ten wird, wel­che Funk­tio­nen mit wel­chen Tech­ni­ken erreicht wer­den sol­len, son­dern auch die rol­len­ba­sier­te Soft­ware-Ent­wick­lung. Sie ermög­licht es jedem an der Ent­wick­lung Betei­lig­ten, sich voll und ganz auf sei­ne spe­zi­fi­sche Auf­ga­be zu kon­zen­trie­ren.

Rol­len­ba­sier­te Soft­ware-Ent­wick­lung

Der Gedan­ke hin­ter der Struk­tur ist ein­fach: Durch die enge Inter­ak­ti­on von Men­schen mit unter­schied­li­chen Schwer­punk­ten wird ein brei­tes Spek­trum abge­deckt und so ein Pro­dukt ent­wi­ckelt, das mög­lichst vie­len Anfor­de­run­gen gerecht wird. Dabei ist es vor allem bei grö­ße­ren Pro­jek­ten drin­gend erfor­der­lich, dass die Inter­ak­ti­on nicht nur münd­lich erfolgt, son­dern auch stark doku­men­ten­ba­siert ist.

Die Rol­le

Unter der Rol­le ver­steht man in der rol­len­ba­sier­ten Ent­wick­lung eine Men­ge zusam­men­ge­hö­ri­ger Auf­ga­ben, Qua­li­fi­ka­tio­nen und Befug­nis­se. Sie kann von einer oder meh­re­ren im Team zusam­men­ar­bei­ten­den Per­so­nen wahr­ge­nom­men wer­den. Gleich­zei­tig kann ein Team oder eine Per­son auch meh­re­re Rol­len erfül­len.

Fol­gen­de Rol­len kön­nen in einem Soft­ware­pro­jekt besetzt wer­den.

1. Pro­jekt­ma­na­ger
Sei­ne wesent­li­chen Auf­ga­ben sind die Pla­nung, Kon­trol­le und Steue­rung des Pro­jekts.
2. Risi­ko­ma­na­ger
Sei­ne Auf­ga­be ist es, poten­zi­el­le Pro­ble­me zu erken­nen und ent­spre­chend Abhil­fe zu schaf­fen. Er ist in alle Pha­sen des Pro­jekts invol­viert.
3. Der Qua­li­täts­ma­na­ger
Er hat eine pro­jekt­be­glei­ten­de Auf­ga­be und ist ver­ant­wort­lich für die Qua­li­tät des erzeug­ten Pro­dukts. Er stellt Anfor­de­run­gen, über­wacht deren Ein­hal­tung und küm­mert sich um Maß­nah­men zur Qua­li­täts­si­che­rung.

Wei­te­re Rol­len sind der Kon­fi­gu­ra­ti­ons­ma­na­ger, der Anfor­de­rungs­ana­ly­ti­ker, Kon­zep­tio­nier, Desi­gner und letzt­lich der Pro­gram­mie­rer. Kom­plet­tiert wird das Gan­ze durch den Tes­ter, den Sys­tem­tech­ni­ker, den Tech­no­lo­gie­be­ra­ter, den War­tungs­ex­per­ten, den Daten­samm­ler, den Soft­ware-Pro­zess­ver­bes­se­rer, den Wie­der­ver­wen­der und die ent­spre­chen­den Ver­ant­wort­li­chen auf den Füh­rungs­ebe­nen.

Rol­len in der Soft­ware­ent­wick­lung

Nicht alle der auf­ge­führ­ten Rol­len wer­den in jedem Soft­ware­pro­jekt besetzt. Doch die wich­tigs­ten, wie Pro­jekt­ma­na­ger und Qua­li­täts­ma­na­ger, aber auch die Pro­gram­mie­rer fin­den sich so in jeder erfolg­rei­chen Soft­ware-Ent­wick­lung wie­der.

Bei der Soft­ware­ent­wick­lung kön­nen Pro­ble­me auf­tre­ten, die Fol­gen nach sich zie­hen: Es besteht die Gefahr, dass die ursprüng­lich geplan­ten Ent­wick­lungs­kos­ten über­schrit­ten wer­den und sich die Ent­wick­lungs­dau­er in die Län­ge zieht. Zudem besteht die Gefahr, dass das End­pro­dukt qua­li­ta­ti­ve Män­gel auf­weist.

Pro­gram­mier­stan­dards müs­sen ein­ge­hal­ten wer­den

Wenn jeder Ent­wick­ler Pro­gram­mier­stan­dards auf sei­ne eige­ne Wei­se inter­pre­tiert, kann es zu erheb­li­chen Dis­kre­pan­zen bei den Ergeb­nis­sen kom­men, wodurch auf­wen­di­ges Nach­ar­bei­ten nötig wird. Es emp­fiehlt sich, inter­ne Hand­bü­cher mit den Pro­gram­mier­stan­dards zur Ver­fü­gung zu stel­len und vor allem dar­auf zu ach­ten, dass die­se von den Pro­jekt­mit­ar­bei­tern auch ver­wen­det wer­den.

Auf die fach­li­che Qua­li­fi­ka­ti­on der Mit­ar­bei­ter ach­ten, die am Pro­jekt betei­ligt sind

Bei jedem Pro­jekt soll­te sicher­ge­stellt sein, dass sämt­li­che invol­vier­te Mit­ar­bei­ter fach­lich aus­rei­chend qua­li­fi­ziert sind. Dies gilt beson­ders für sehr kom­ple­xe Soft­ware­pro­jek­te, an denen vie­le Ent­wick­ler betei­ligt sind. Eben­so ist es wich­tig, dass die ein­zel­nen Mit­ar­bei­ter über ein ähn­li­ches fach­li­ches Niveau ver­fü­gen, um Ver­stän­di­gungs­schwie­rig­kei­ten unter­ein­an­der zu ver­mei­den.

Stän­dig neue Mit­ar­bei­ter ins Team holen

Bei der Soft­ware­ent­wick­lung soll­te ver­mie­den wer­den, dass wäh­rend eines lau­fen­den Pro­jekts die damit beauf­trag­ten Ent­wick­ler aus­schei­den und durch neue Mit­ar­bei­ter ersetzt wer­den. Denn ver­lässt ein Mit­ar­bei­ter wäh­rend der Ent­wick­lung das Unter­neh­men oder wech­selt zu einem ande­ren Pro­jekt, gehen die bis­her gesam­mel­ten Erfah­run­gen mit der wer­den­den Appli­ka­ti­on meist ver­lo­ren. Erfah­rungs­ge­mäß ist es äußerst schwer, das Wis­sen eines aus­schei­den­den Mit­ar­bei­ters auf den neu­en Ent­wick­ler zu über­tra­gen.

Für kla­re Pro­zes­se sor­gen

Intrans­pa­ren­te Abläu­fe in der Soft­ware­ent­wick­lung füh­ren zur Ver­un­si­che­rung der Betei­lig­ten. Miss­ver­ständ­nis­se ent­ste­hen, wodurch sich Feh­ler ein­schlei­chen, die nur durch einen erhöh­ten Auf­wand wie­der besei­tigt wer­den kön­nen und das Pro­jekt zieht sich unnö­tig in die Län­ge. Es wird emp­foh­len, die Anwen­dungs­ent­wick­lung im Sys­tem von Pro­duk­ti­ons­stra­ßen auf­zu­bau­en.

Prio­ri­tä­ten set­zen

Es fällt immer wie­der auf, dass bezüg­lich der geplan­ten Fea­tures kei­ne Prio­ri­tä­ten gesetzt wer­den, was meist zur Fol­ge hat, dass die Fea­tures in der fal­schen Rei­hen­fol­ge abge­schlos­sen wer­den. Des­halb soll­te ein Team im Vor­feld ent­schei­den, wel­cher Arbeits­schritt als Ers­tes ange­gan­gen wird. Es emp­fiehlt sich, die Ent­schei­dung intern vor­zu­neh­men und den Auf­trag­ge­ber außen vor zu las­sen. Denn Auf­trag­ge­bern fehlt oft die Über­sicht, wel­ches Fea­ture für den Erfolg des Pro­jekts beson­ders wich­tig ist.

Die Wahl der rich­ti­gen Soft­ware im Unter­neh­men und der dazu gehö­ren­den Tech­nik im Hin­ter­grund ist eine grund­le­gen­de Fra­gen. Hier kann es z.B. um die Ver­wal­tung von Daten und Doku­men­te gehen. Jede vor­han­de­ne Lösung hat Vor- und Nach­tei­le. Gera­de in grö­ße­ren Unter­neh­men, aber vor allem in spe­zia­li­sier­ten Fir­men kön­nen die Stan­dard­lö­sun­gen nicht immer das opti­ma­le Paket bie­ten, mit dem z.B. Doku­men­te oder ande­re Daten ver­wal­tet wer­den kön­nen. Daher geht der Trend zur indi­vi­du­el­len Soft­ware­lö­sung.

Hier­bei spie­len ver­schie­de­ne Über­le­gun­gen eine Rol­le: Eine typi­sche Vor­aus­set­zung ist sicher, wenn die bestehen­den Stan­dard­pro­duk­te zwar gut ins Kon­zept pas­sen, aber gegen­über einer zuge­schnit­te­nen, indi­vi­du­el­len Vari­an­te schlicht teu­rer sind. In vie­len Fäl­len sind kei­ne Stan­dard­pro­duk­te vor­han­den, die die gefor­der­ten Auf­ga­ben erfül­len kön­nen. Weit kom­ple­xe­re Grün­de sind die Unab­hän­gig­keit vom Anbie­ter. Hat man sich früh für eine Stan­dard­soft­ware ent­schie­den, ist man vom Wil­len zu mög­li­chen Ver­än­de­run­gen die­ses Anbie­ters abhän­gig und kann nicht mehr ohne gro­ßen Auf­wand in ein viel­leicht bes­se­res Sys­tem wech­seln. Eine eige­ne opti­mier­te Soft­ware­lö­sung kann somit auch ein ent­schei­den­der Vor­teil gegen­über der Kon­kur­renz sein. Eine opti­ma­le Soft­ware­lö­sung kann die Bezie­hung zum Kun­den ein­fa­cher, trans­pa­ren­ter und somit bes­ser gestal­ten.

Die prak­ti­schen Vor­tei­le und Begrün­dun­gen las­sen sich wie folgt zusam­men­fas­sen: Indi­vi­du­el­le Lösun­gen kön­nen bes­ser auf bestimm­te Vor­aus­set­zun­gen und Anfor­de­run­gen ange­passt wer­den. Gleich­zei­tig sind sie damit auch bes­ser in der Lage, mit den stei­gen­den Anfor­de­run­gen ergänzt zu wer­den und somit zu wach­sen. Der Auf­wand für Mit­ar­bei­ter­schu­lun­gen wird meist erheb­lich ver­rin­gert, wenn die Ein­ga­be­mas­ken an die bestehen­den Betriebs­ab­läu­fe und das Voka­bu­lar ange­passt sind. Zusätz­lich kön­nen not­wen­di­ge Regeln und Plau­si­bi­li­täts­prü­fun­gen mög­lich gemacht wer­den, die auto­ma­tisch ver­hin­dern, dass Auf­trä­ge mehr­fach bear­bei­tet wer­den müs­sen. Mit die­sen varia­blen Bestand­tei­len kann die eige­ne Soft­ware­lö­sung opti­mal an die bestehen­den Sys­te­me und Anfor­de­run­gen ange­passt wer­den und ermög­licht es dem Unter­neh­men, sei­ne Res­sour­cen opti­mal und gewinn­brin­gend ein­zu­set­zen. Sind die Ziel­kri­te­ri­en klar defi­niert, kön­nen Anbie­ter für Indi­vi­dual­lö­sun­gen ein Pro­dukt zusam­men­stel­len, dass die bestehen­den Sys­te­me und die neue Benut­zer­ober­flä­che auf­ein­an­der abstimmt und mit­ein­an­der ver­netzt. Spä­te­re Ände­run­gen oder Erwei­te­run­gen sind auf die­sem Weg ein­fa­cher zu bewerk­stel­li­gen.