Digitalisierung von Workflows mit JIRA

More documents

Recommendations

Info

14 BTS NR. 26 le Sicherheitslücken. Zu einem Problem werden solche Lücken immer dann, wenn sie zwar jemand entdeckt, sie aber geheim hält, weil er keine guten Absichten hat oder sie zu kriminellen Zwecken nutzen will. Gerüchten zufolge bezahlen sogar Geheimdienste Hacker dafür in bestimmten IT-Systemen nach unbekannten Sicherheitslücken zu suchen. Aber nicht, um diese öffentlich zu machen, sondern um sich darüber unbemerkt Zugriff auf Daten zu verschaffen. Die Krux an dieser Sache: In solchen Fällen erfahren die Hersteller oder die Open Source Community gar nicht oder erst sehr spät von der Lücke und können diese auch nicht zeitgerecht schließen. Nur wenn die Sicherheitslücke bekannt wird, kann der Hersteller Gegenmaßnahmen ergreifen und sie schließen. In der Realität dauert dieser Vorgang vielfach Wochen oder Monate. Je bekannter eine Lücke wird, desto mehr Informationen erhalten potenzielle Angreifer im Internet über die Schwachstelle. Ab einem gewissen Bekanntheitsgrad sind selbst Hobby-Hacker in der Lage eine Sicherheitslücke zu überwinden und Schaden anzurichten. Positiv ist auf der anderen Seite, dass immer mehr Nutzer informiert werden. Sie können sich anschließend gegen mögliche Angriffe schützen oder die betroffene Software temporär nicht benutzen. In diesen Fällen spielt der Hersteller in der Regel kurzfristig einen Patch ein, wobei es trotzdem oft sehr lange dauert, bis die Gefahr gebannt und eine Sicherheitslücke komplett geschlossen wird. Bei den vielen Problemen, die durch Bugs verursacht werden, steht der bestmögliche Schutz vor Problemen, die mit Softwarefehlern im Zusammenhang stehen, nicht nur bei der ADACOR, sondern in jeder Unternehmens-IT im Mittelpunkt. Software Bugs – alles Definitionssache? Neben der korrekten Einteilung von Bugs in verschiedene Kategorien, besteht eine weitere Herausforderung in der Definition eines Softwarefehlers. Über die korrekte Begriffsbestimmung herrschen unterschiedliche Meinungen. Sebastian Krack, Leiter der Softwareentwicklung bei ADACOR, definiert einen Bug zum Beispiel wie folgt: „Wenn der Quellcode nicht genauso abläuft, wie der Entwickler es sich gedacht hat oder entscheidende Gegebenheiten bei der Programmierung nicht bedacht wurden, ist es ein Bug“. Neben der Programmierersicht lautet eine Definition aus der Businessperspektive so: „Um einen Softwarefehler als solchen zu definieren, bedarf es einer genauen Spezifikation der gewünschten Funktionsweise der Software und erst eine Abweichung von dieser stellt einen Fehler dar.“ Ein typisches Beispiel für Probleme, die aus einer fehlenden Spezifikation entstehen können, ist die ungeplante Skalierung der Software. So wird etwa eine Software für einen kleinen Personenkreis mit überschaubarem Budget entwickelt und implementiert. Für diese Nutzergruppe funktioniert das Programm einwandfrei. Die Software begeistert nach und nach immer mehr Nutzer, sodass deren Anzahl steigt. Nachdem nicht mehr nur 15, sondern 200 Personen die Software regelmäßig nutzen, kommt es laufend zu Problemen und Abstürzen. Die dafür ursächlichen Softwarefehler sind dann eigentlich keine richtigen Fehler, sondern Teil der ursprünglichen Konzeption. Denn diese basiert auf einer kleinen Nutzergruppe, für die es weder die Anforderung noch das Budget für eine Skalierbarkeit gab. Folgerichtig wurde auf jeden Mehraufwand für Skalierbarkeit und entsprechende Performance-Optimierung verzichtet. Daraus lässt sich schlussfolgern, dass theoretisch bei jeder Softwarekonzeption von Anfang an genau klar sein müsste, wie die genauen Anforderungen an das Programm in Zukunft aussehen werden. In der Praxis ist diese Voraussicht in vielen Fällen nicht möglich. Es ist im Gegenteil sogar extrem schwierig, die genauen Vorgaben an eine Software vor Projektbeginn zu definieren. Diese Erkenntnisse berücksichtigen jedoch moderne agile Projektframeworks wie Scrum oder Kanban, die auch bei der ADACOR zum Einsatz kommen. Je mehr Planung also in die Definition von Anforderungen oder in deren Unschärfe in der Konzeptionsphase fließen und je besser die Projektmanagement-Methoden sind, desto weniger Probleme gibt es hinterher bei der Entwicklung. Kombinierte Testverfahren stellen Softwarequalität am ehesten sicher Grundsätzlich ist das ausgiebige Testen einer Software die offensichtlichste Methode, um Fehler möglichst frühzeitig zu erkennen. Neben verschiedenen anderen Prüfmethoden ist der manuelle Test am bekanntesten. Dabei handelt es sich um eine Variante des sogenannten Black-Box-Testings, bei dem ohne Kenntnis des Softwarecodes (wie in einer Black Box) gegen die Spezifikation getestet wird. Die Tester gehen die Anwendung Schritt für Schritt durch und überprüfen, ob alle Features wie erwartet funktionieren. Damit der Tester aufgrund seiner eigenen Entwicklung nicht unbewusst Annahmen über die Nutzung der Software trifft, sollte ein Entwickler nicht gleichzeitig auch Tester sein. Der Nachteil dieser Testmöglichkeit besteht darin, dass nur Fehlerbilder geliefert werden, aber keine Ursachen. Um Fehler in größeren Projekten einer bestimmten Komponente zuweisen zu können, benötigt man sogenannte White- Box-Tests, bei denen der Quellcode selbst getestet wird. Da es bei größeren Projekten immer aufwendiger wird, den Code manuell zu testen, kommen in einem solchen Fall immer häufiger automatisierte Tests zum Einsatz. Ein weit verbreitetes Verfahren ist dabei der Unit-Test bzw. Modultest, bei dem jedes Softwaremodul einzeln getestet wird, um die Komplexität zu reduzieren. Das bedeutet konkret, dass für jedes Modul ein eigenes Testprogramm, welches die Funktionen des Moduls gegen die Spezifikation testet, geschrieben wird. Automatisierte Tests, die in der Regel vom selben Softwareentwickler geschrieben werden wie der Code, finden jedoch nur solche Fehler, die bereits bei der Testkonzeption berücksichtigt wurden. Ein grundlegender Denkfehler bezogen auf die Implementierung könnte sich hingegen in den Tests fortsetzen. Um diesen Nachteil auszugleichen, werden in der Praxis manuelle Black-Box-Tests mit einem unabhängigen Team mit automatisierten White-Box-Tests zur Fehlersuche kombiniert.
15 Komplexe Konstellationen mithilfe von Betaphasen checken Die nächste Stufe des Softwaretests umfasst die Betaphase, welche die meisten Nutzer schon einmal bei einem Webdienst erlebt haben. In diesem Stadium wurde die Software hinter einem Dienst bereits intern getestet und das Programm arbeitet im besten Fall weitgehend fehlerfrei. In seltenen Konstellationen, die vielleicht in den Tests nicht berücksichtigt wurden, werden jedoch noch Fehler erwartet. Um diese Bugs zu finden, wird die Software bzw. der Dienst mit dem Hinweis auf die Betaphase veröffentlicht und in der Regel bis zum Abschluss dieser Stufe kostenlos angeboten. In diesem Zeitraum sind die Nutzer aufgerufen, Fehler zu melden. Damit kann der Anbieter auch Fehler finden, die nur in speziellen Situationen auftreten oder die beim internen Testen übersehen wurden. Dieses Vorgehen ist allerdings nur bei Software möglich, die eine breite Nutzerbasis hat. Typisch ist das bei großen Internetunternehmen. Wenn man eine kleine oder mittlere Auftragsentwicklung mit einem neuen Google-Dienst vergleicht, ist das natürlich nicht fair, da man nicht immer 20.000 Betatester parat hat. Fazit ›› Ein wichtiger Bewertungsmaßstab für die Qualität einer Software ist immer die ursprünglich und individuell zu Grunde gelegte Konzeption. Deckt sich bei der Einführung die Grundkonzeption nicht mit den tatsächlichen Gegebenheiten im Unternehmen (z. B. im Hinblick auf die Skalierbarkeit der User-Anzahl), kann es bei der Implementierung der Software zu Problemen kommen. Diese sind dann weniger einer fehlerhaften Programmierung geschuldet, als vielmehr der Diskrepanz zwischen den vom Hersteller für die Programmierung festgelegten Spezifikationen und den tatsächlichen Einsatzbedingungen vor Ort beim Kunden. ›› Hiervon abgesehen existiert eine Menge rein objektiver Kategorien von Softwarefehlern, die bei der Programmierung selbst entstehen. In diesem Kontext ist es wichtig, sich vor Augen zu führen, dass Fehler zur Softwareentwicklung dazugehören. Komplexe Systeme beinhalten immer Fehler - und zwar unabhängig davon, welches Programm oder Endgerät genutzt wird. Trotz der diversen Konzepte zur Fehlervermeidung werden Software Bugs die IT auch in Zukunft begleiten. Es gibt in dieser Hinsicht keine absolute Sicherheit. THOMAS WITTBECKER Geschäftsführer I CEO ADACOR Hosting GmbH Emmastraße 70 A 45130 Essen TELEFON +49 69 900299-24 TELEFAX +49 69 900299-29 E-MAIL thomas.wittbecker@adacor.com INTERNET www.adacor.com
Page 1 and 2: NR. 26 ADACOR BRANCHENINFORMATION A
Page 3 and 4: expect more Liebe Leserinnen und Le
Page 5 and 6: 5 Gastbeitrag von brainbits zu Atla
Page 7 and 8: 7 2.3 ORGANISATION DES EINKAUFS Ent
Page 9 and 10: 9 Die Aufgaben der ADACOR beim Open
Page 11 and 12: 11 Nicole Jordan und Christoph Gedw
Page 13: 13 Fehlermanagement im Softwarebere
Page 17 and 18: 17 IT Service Controlling IT Manage
Page 19 and 20: 19 Um eine aussagekräftige Kennzah
Page 21 and 22: 21 optimiert Arbeitsabläufe: Ist e
Page 23 and 24: 23 den Auftragsdatenvereinbarungen
Page 25 and 26: 25 langen Wartezeiten zu vermeiden,
Page 27 and 28: 27 einer Karte per Telefon das Gebu
Page 29 and 30: 29 Medien kreativ begreifen Spenden
Page 31 and 32: 31 Einsatz von DNS in der Netzwerkt
Page 33 and 34: 33 Domain-Registrierung und Eintrag
Page 35 and 36: 35 Im Porträt: Patrick Fend - Gesc
Page 37 and 38: 37 Cubebot als Dankeschön Ich will
Page 39 and 40: 39 WIR SAGEN DANKE! ›› Für die

Digitalisierung von Workflows mit JIRA

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?