die nächsten 37 Jahre
Überraschenderweise wurde ich auf einen Eintrag auf einer schon lange vernachlässigten Blogseite mit dem Titel "Das 37. Jahr" angesprochen. Mittlerweile müsste es "Das 40. Jahr" heißen, aber das tut jetzt nichts zur Sache.
Die Frage war: wie wird sich Software und mein Gebiet Test in den nächsten 37 Jahren entwickeln.
In den letzten 37 Jahren habe ich Technologien kommen und auch schon wieder gehen sehen, von denen ich als Kind nicht glauben hätte mögen, dass sie möglich sind. Eigenartigerweise waren das nicht die genauso utopistischen Dinge wie Mobile Phones oder Laptops. Vielmehr las ich kürzlich, dass das Telefax ähnlich wie das Telex in Vergessenheit geraten wird, wenn die digitale Signatur einmal allgemeine Gültigkeit und durchgängigen Gebrauch erfährt.
Die Frage richtete sich aber nach den Inhalten Qualität und Test aus.
Wird es eine Veränderung geben?
Ich sage ja.
Bis heute hält sich eine merkwürdige Konstante in der Software-Entwicklung. Es ist die Anzahl der Gesamtfehler in einem Programm bezogen auf die Große (gemessen in Code-Zeilen) oder auf die ausgelieferte Funktionalität (gemessen in Function Points).
Dies erscheint paradox, weil die Werkzeuge zur Software-Erstellung immer leistungsfähiger und vor allem hilfreicher werden. Ein allfälliger Nutzeffekt konnte aber bisher nicht lukriert werden, weil im gleichen Zeitraum die Komplexität der Programme in astronomischen Maßstäben gestiegen ist.
Jetzt könnte das Spiel endlos lange - ohne Veränderungen der Parameter - weitergehen.
Ich behaupte aber, dass die Komplexität der Programme durch eine Zunahme der Anforderungen steigt. Da denke ich nun, dass wir bald keine neuen Anforderungen mehr erfinden werden können, ohne dass die Anforderungen in Richtung verstärkte Robustheit, bessere Konnektivität und bessere Fehlerbehandlung gehen. Alle diese Merkmale wirken aber auch indirekt auf die Qualität des Codes zurück. Bei weiterhin zunehmender Werkzeugverbesserung und weniger rasant ansteigender Komplexität wird sich insgesamt die Qualität der Software erhöhen. Software Test wird allgemein verstärkt bereits im Anforderungsmanagement eingesetzt werden und die Welt wird schön werden.
Ich bin gespannt, ob ich recht gehabt haben werde.
Die Frage war: wie wird sich Software und mein Gebiet Test in den nächsten 37 Jahren entwickeln.
In den letzten 37 Jahren habe ich Technologien kommen und auch schon wieder gehen sehen, von denen ich als Kind nicht glauben hätte mögen, dass sie möglich sind. Eigenartigerweise waren das nicht die genauso utopistischen Dinge wie Mobile Phones oder Laptops. Vielmehr las ich kürzlich, dass das Telefax ähnlich wie das Telex in Vergessenheit geraten wird, wenn die digitale Signatur einmal allgemeine Gültigkeit und durchgängigen Gebrauch erfährt.
Die Frage richtete sich aber nach den Inhalten Qualität und Test aus.
Wird es eine Veränderung geben?
Ich sage ja.
Bis heute hält sich eine merkwürdige Konstante in der Software-Entwicklung. Es ist die Anzahl der Gesamtfehler in einem Programm bezogen auf die Große (gemessen in Code-Zeilen) oder auf die ausgelieferte Funktionalität (gemessen in Function Points).
Dies erscheint paradox, weil die Werkzeuge zur Software-Erstellung immer leistungsfähiger und vor allem hilfreicher werden. Ein allfälliger Nutzeffekt konnte aber bisher nicht lukriert werden, weil im gleichen Zeitraum die Komplexität der Programme in astronomischen Maßstäben gestiegen ist.
Jetzt könnte das Spiel endlos lange - ohne Veränderungen der Parameter - weitergehen.
Ich behaupte aber, dass die Komplexität der Programme durch eine Zunahme der Anforderungen steigt. Da denke ich nun, dass wir bald keine neuen Anforderungen mehr erfinden werden können, ohne dass die Anforderungen in Richtung verstärkte Robustheit, bessere Konnektivität und bessere Fehlerbehandlung gehen. Alle diese Merkmale wirken aber auch indirekt auf die Qualität des Codes zurück. Bei weiterhin zunehmender Werkzeugverbesserung und weniger rasant ansteigender Komplexität wird sich insgesamt die Qualität der Software erhöhen. Software Test wird allgemein verstärkt bereits im Anforderungsmanagement eingesetzt werden und die Welt wird schön werden.
Ich bin gespannt, ob ich recht gehabt haben werde.
steppenhund - 19. Aug, 08:21
read 262 times
Sind
...und
NEIN!
@pathologe
Außerdem sind die Werkzeuge wirklich ziemlich saugut.
Ich kann z.B. ein Werkzeug anführen, von dem ich weiß, dass im ersten Jahr Produktion die Fehlerzahl einstellig bleiben musste. Das war bereits in der Zielsetzung der Entwicklung des Werkzeugs so vorgegeben.
Es handelte sich um den REXX-Compiler (nicht den Interpreter), der im IBM-Labor in Wien entwickelt wurde.
Compiler an sich sind recht fehlerfrei. Darauf muss man sich einfach verlassen können. Aber seit einigen Jahren ist es normal, dass Programmiersprachen farblich gemäß der Syntax unterlegt sind. Das hilft z.B. sehr.
In den Entwicklungsplattformen sind automatische Rule-Checker eingebunden, mit denen vollautomatisch überprüft wird, ob bestimmte Regeln eingehalten werden.
Die neueste Ausgabe von Visual Studio 2010 Ultimate Edition (MS) unterstützt den gesamten Software Development Life Cycle in einer Form, wie ich sie nicht für möglich gehalten hätte. Das Ding kostet allerdings auch 14.000 € pro Lizenz.
Nein, die Fehler der Werkzeuge gehen in das Endprodukt praktisch gar nicht ein. Es sind die Fehler in den Anforderungen - sprich den Wünschen, was man eigentlich tun will - die weh tun. In einem Program sind 43% der Gesamtfehler bereits durch die Anforderungen verursacht, die schlecht, unvollständig oder falsch formuliert sind. (43% war die Zahl im Jahr 2000, heute werden 60% in manchen Studien angegeben)
Der Mensch ist der Fehler, nicht die Werkzeuge.
;-)
@vm