Anbieter zum Thema
„Bestandscode ist eine tickende Zeitbombe“
Es gab vor Kurzem ja eine ganze Welle mit Ransomware. Sogar Krankenhäuser wurden von dieser Malware komplett lahmgelegt. Und das ist eine gruselige Vorstellung.
Einige Firmen haben es komplett aufgegeben, Angriffen vorzubeugen. Sie versuchen stattdessen zu erkennen, dass sie angegriffen werden, um diese Attacken dann zu stoppen.
Man weiß: Die Attacken kommen auf jeden Fall, man kann sie nicht im Vorfeld abwehren. Man kann aber den Internet-Traffic analysieren und ungewöhnliche Muster aufspüren, um zu erkennen, dass man gehackt wird, und sich dann abschalten.
Wir nehmen auf jeden Fall wahr, dass immer mehr Menschen sagen: „Hör zu, wir haben diese Mengen an altem Code. Da Softwareentwicklung so teuer ist, versuchen wir ihn so lange zu nutzen, wie es geht, bevor wir letztendlich aufgeben und alles neu machen müssen.“ Daran gibt es ein unglaubliches Interesse.
Deshalb entwickeln wir eine automatische Technik, die es erlaubt, einen Grundbestand an Testfällen zu erzeugen. Wenn man nämlich eine Applikation draußen im Feld hat, dann funktioniert die Software ja irgendwie und es gibt auch eine Wartungsgeschichte dafür.
Vielleicht ist die Software nicht ausreichend getestet, aber sie ist immerhin ein paar Jahre im Betrieb. Sie haben auch Bugs gefixt, Ihre Kunden haben auch ihre Erfahrungen damit gemacht, also verhält sie sich erwartbar. Wenn die Software ein paar Jahre lang in Betrieb ist, und man validiert, man dokumentiert, man formalisiert, was sie tut, dann ist das schon einiges wert.
Verstehen die Unternehmen denn, dass bei ihnen im Keller eine Zeitbombe tickt?
Immer mehr verstehen es. Eine Reihe von Interessenten oder gar Bestandskunden sagen zu uns: „Wir wissen, dass wir ein großes Problem mit unserem bestehenden Code haben.“ Das heißt, dass sie wissen, dass sie ein Qualitätsdefizit haben.
Jeder, der Code produziert, weiß, wo die Probleme liegen. Deshalb arbeiten wir zur Zeit an einem webbasierten Qualitätsmonitor für VectorCast Analytics. Er erlaubt Ihnen auf sehr einfache Weise Qualitätsmerkmale zu prüfen, etwa die Komplexität, die Größe oder die Kommentardichte. Damit können Sie sehen, wo Sie stehen und worauf Sie sich konzentrieren sollten.
Denn bei dem Bestandscode-Problem stellt sich jeder die Frage, wo man anfangen soll. Selbst mit Werkzeugen zur statischen Analyse bekommt man ja Millionen von Bugs angezeigt. Man kann sie aber nicht alle auf einmal fixen. Die Zeit reicht einfach nicht. Aber wir können unsere begrenzten Ressourcen intelligent an der Stelle einsetzen, wo es am meisten nützt.
Die Analyse zeigt zum Beispiel anhand von Farben die Codeabdeckung an. Jetzt habe ich etwa ein richtig komplexes Symbol, das komplett rot eingefärbt ist. Das zeigt Ihnen, dass es sehr komplex ist und dass die Komponente kaum getestet wurde. Wenn Sie ganz kleine Symbole haben, die alle grün sind, dann haben Sie die einfachen Sachen getestet. Sie sollten sich also auf die schwierigen Dinge konzentrieren.
Eine andere Analyse, die Sie vornehmen können: Welcher Code ändert sich am häufigsten? Wenn sich Module täglich verändern, dann sind das mit einiger Wahrscheinlichkeit Ihre Sorgenkinder. Denn wenn sich diese Module jeden Tag ändern, dann fügen Sie entweder jeden Tag neue Funktionen hinzu oder Sie reparieren eine ganze Menge Fehler.
Eine andere interessante Sache ist: Wie viel Zeit verwenden die Entwickler darauf, Bugs zu fixen? Wir wollen ja, dass unsere Entwickler neue Software erstellen, neue Funktionen, die die Kunden zufriedenstellen.
Aber wenn wir an den Punkt kommen, an dem die Entwickler zu 90 oder zu hundert Prozent Fehler beheben, dann sind wir gefesselt, nicht wahr? Wenn Sie ein Bauunternehmen wären und Ihre Mitarbeiter würden zu 90 Prozent löchrige Dächer stopfen oder Rohre reparieren, die nicht richtig installiert wurden, dann wären Sie schnell pleite.
Artikelfiles und Artikellinks
(ID:44602436)