Beiträge

Die Ent­wick­lung einer Soft­ware ist mit einem gro­ßen Zeit- und Geld­auf­wand ver­bun­den, den es vor­ab zu kal­ku­lie­ren gilt, denn bei fast allen Pro­jek­ten über­stei­gen die fina­len Kos­ten die eigent­li­chen Erwar­tun­gen. Grund dafür sind die feh­len­den oder fal­schen Metho­den der Unter­neh­men, die Kos­ten für die Soft­ware­ent­wick­lung rich­tig zu kal­ku­lie­ren. Dabei gilt die Schätz­me­tho­de als die bewähr­tes­te, denn so kann der Ent­wick­ler inner­halb eines ver­ein­bar­ten Bud­gets pla­nen und arbei­ten. Bei solch einer Kos­ten­pla­nung wer­den alle Leis­tun­gen mit den ent­spre­chen­den Kos­ten fest­ge­hal­ten, die wäh­rend des Pro­jekts anfal­len wer­den. Wo die Kos­ten bis dato noch nicht exakt ermit­telt wer­den kön­nen, wer­den Schät­zun­gen ver­an­lasst, um so bes­ser und schnel­ler pla­nen zu kön­nen. Pro­blem an die­ser Schätz­me­tho­de ist, dass die­se immer recht unge­nau ist — eben nur geschätzt. Vor allem in der Soft­ware­ent­wick­lung kön­nen die Kos­ten häu­fig die Erwar­tun­gen über­stei­gen. Ist man sich bei den Schät­zun­gen unsi­cher, kann man auch auf Ver­gleichs­wer­te aus bis­he­ri­gen inter­nen Pro­jek­ten set­zen. Ent­we­der erge­ben sich die­se aus Erfah­rungs­wer­ten des eige­nen Unter­neh­mens oder aus ande­ren Ange­bo­ten, die auf Anfra­ge ein­ge­holt wur­den.

Sach­mit­tel­auf­wand in der Soft­ware­ent­wick­lung

Die wich­tigs­ten Kom­po­nen­ten, die das Soft­ware­pro­jekt ver­ei­nen, set­zen sich zum einen aus dem Sach­mit­tel­auf­wand zusam­men. Hier­zu zäh­len unter ande­rem Mate­ria­li­en, die vor­ran­gig für das jewei­li­ge Pro­jekt, ein­ge­kauft wer­den müs­sen, da sie direkt in die­ses ein­ge­bun­den wer­den. Dies kön­nen neben benö­tig­ter Lite­ra­tur auch Soft­ware, Werk­zeu­ge oder ande­re Arbeits­mit­tel sein. Die Kos­ten für sol­che Arbeits­mit­tel las­sen sich anhand von ver­bind­li­chen Ange­bo­ten oder Auf­trags­be­stä­ti­gun­gen erfra­gen und kön­nen als Grund­la­gen für die Schät­zung ver­wen­det wer­den. Wei­te­re Kos­ten, die bei einem Soft­ware­pro­jekt anfal­len, sind die inter­nen und exter­nen Auf­wen­dun­gen. Je nach Bran­che kön­nen auch exter­ne Spe­zia­lis­ten dem Team kurz­zei­tig zu Rate gezo­gen wer­den und ver­an­schla­gen neben den inter­nen Per­so­nal­kos­ten auch exter­ne Kos­ten, die es zu beglei­chen gilt. Dem­nach gibt es eine Viel­zahl von Fak­to­ren, die es bei einer Soft­ware­ent­wick­lung zu beach­ten gilt.

Unter agi­ler Soft­ware­ent­wick­lung ver­steht man gemein­hin einen häu­fig auf­tre­ten­den Rück­kopp­lungs­pro­zess, sowie ein all­um­span­nen­des zykli­sches Vor­ge­hen, das sowohl die Pro­gram­mie­rung als auch das Manage­ment mit ein­schließt. Wäh­rend die klas­si­sche Vor­ge­hens­wei­se das neue Sys­tem bis in die letz­ten Ein­zel­hei­ten im Vor­aus plant, wech­seln sich bei der agi­len Soft­ware­ent­wick­lung kur­ze Pla­nungs- und Ent­wick­lungs­pha­sen ab. Wei­ter­le­sen

Das Arbei­ten mit Soft­ware ist in den letz­ten Jahr­zehn­ten für die meis­ten Men­schen zu einem ganz gewohn­ten und auch wich­ti­gen Teil ihres All­tags gewor­den. Egal ob wir im Inter­net sur­fen, Brie­fe oder E-Mails schrei­ben oder am Arbeits­platz mit fir­men­in­ter­nen Pro­gram­men kon­fron­tiert sind, der siche­re Umgang mit Soft­ware wird heut­zu­ta­ge erwar­tet und vor­aus­ge­setzt. Pro­ble­ma­tisch wird es erst, wenn eine Soft­ware für einen Men­schen eine Bar­rie­re dar­stellt. Far­ben wer­den schlecht oder gar nicht erkannt, Töne nicht gehört oder Tex­te kön­nen nicht gele­sen wer­den. Die bar­rie­re­freie Soft­ware­ent­wick­lung setzt genau dort an.

Was ist bar­rie­re­freie Soft­ware­ent­wick­lung?

Pro­gram­me, die für jeden Men­schen mit kör­per­li­cher oder geis­ti­ger Ein­schrän­kung geeig­net sind, wer­den bar­rie­re­freie Pro­gram­me genannt. Eine kör­per­li­che Ein­schrän­kung kann das limi­tier­te oder nicht vor­han­de­ne Seh­ver­mö­gen sein, hier müs­sen Alter­na­ti­ven für den regu­lä­ren Text gefun­den wer­den. Bei Men­schen ohne Hör­ver­mö­gen kön­nen akus­ti­sche Signa­le zum Bei­spiel beim E-Mail Ein­gang nicht genutzt wer­den. Men­schen mit einer Rot-Grün-Seh­schwä­che müs­sen ande­re Far­ben ange­bo­ten wer­den. Auch Senio­ren kom­men mit bar­rie­re­frei­er Soft­ware oft bes­ser zurecht, hier muss zum Bei­spiel auf die ver­min­der­te Reak­ti­ons­zeit und grö­ße­re Tex­te oder die Anwend­bar­keit einer Bild­schirm­lu­pe geach­tet wer­den. Fremd­spra­chi­ge Per­so­nen haben oft Pro­ble­me mit dem Text­ver­ständ­nis. Hier kön­nen auto­ma­ti­sche Über­set­zun­gen oder eine ver­ein­fach­te Seman­tik hel­fen.

Was ist wich­tig?

Bar­rie­re­freie Soft­ware­ent­wick­lung muss die ver­schie­dens­ten Aspek­te von Pro­gram­men berück­sich­ti­gen. Je nach Soft­ware und Ziel­grup­pe ist das zum Bei­spiel die Ori­en­tie­rung des Tex­tes oder eine Ersatz­be­schrei­bung für Mul­ti­me­diain­hal­te. Auch Far­ben und Kon­tras­te müs­sen über­prüft und even­tu­ell anpass­bar sein. Tex­te und das Lay­out müs­sen in den unter­schied­lichs­ten Grö­ßen ein­deu­tig erkenn­bar und erfass­bar sein. Beson­ders wich­tig ist auch die Dyna­mik des Pro­gramms: Ist die Soft­ware über die Maus und die Tas­ta­tur steu­er­bar? Kann man womög­lich eine Steue­rung über die Stim­me ermög­li­chen? Auch Ele­men­te zur Navi­ga­ti­on und Ori­en­tie­rung müs­sen kon­sis­tent umge­setzt wer­den, mög­li­cher­wei­se sind hier auch zusätz­li­che Ele­men­te nötig.

Wie wird Soft­ware auf Bar­rie­re­frei­heit über­prüft?

Für Ent­wick­ler ist es wesent­lich ein­fa­cher, die Bar­rie­re­frei­heit im Vorn­her­ein zu imple­men­tie­ren, als sie spä­ter ein­zu­fü­gen. Bereits ent­wi­ckel­te Pro­gram­me kön­nen mit Hil­fe von meh­re­ren Richt­li­ni­en über­prüft wer­den. Beson­ders drei Leit­fä­den haben sich hier in der Pra­xis bewährt:

    1. Die DIN EN ISO 9241–171 Leit­li­ni­en für die Zugäng­lich­keit von Soft­ware
    2. Die Ent­wick­ler-Richt­li­ni­en von IBM (Deve­lo­per Gui­de­li­nes)
    3. Die Richt­li­ni­en für bar­rie­re­freie Web­in­hal­te des World Wide Web Con­sor­ti­um

Die Über­prü­fung eines Pro­gramms ist aber immer noch „Hand­ar­beit“. Es gibt bis heu­te kei­ne eigen­stän­di­gen Pro­gram­me, die dies leis­ten könn­ten. Wäh­rend der Test auf die Kom­pa­ti­bi­li­tät mit der Tas­ta­tur rela­tiv ein­fach durch­zu­füh­ren ist, sind man­che Aspek­te von Soft­ware im Nach­hin­ein nur schwer auf bar­rie­re­frei­es Arbei­ten zu über­prü­fen. Dazu gehö­ren alle Anfor­de­run­gen, die im Quell­code der Pro­gram­mie­rung schwer oder gar nicht mehr zu fin­den sind, wie zum Bei­spiel das Ver­se­hen einer jeden Schnitt­stel­le oder Ele­ments mit einem spe­zi­fi­schen Namen.