Nachhaltige Verbesserung der Software

Hier erfahren Sie viel über ihre Möglichkeiten zur nachhaltigen Verbesserung der Qualität. Mit einfachen Massnahmen und der Pareto-Regel erzielen Sie einen maximalen Ertrag.

1.       Funktionalität

Die Funktionalität wird am besten aus einem Mix von Pflichtenheft, Visualisierung und Use Cases beschrieben, weil damit verschiedene Aspekte berücksichtigt werden.

Folgende Massnahmen bieten sich an:

  • Vollständigkeit, dazu gehören auch die nicht-funktionalen Anforderungen
  • Einfache Sprache, keine Fremdwörter, Erklärung der Begriffe
  • Review intern und mit Kunde: Beginn der Entwicklung erst nach Abnahme der Funktionalität!
  • Ablage der Informationen, sodass alle Projektmitarbeiter darauf Zugriff haben. Sind externe Mitarbeiter involviert, machen Cloud-Lösungen Sinn, z.B. Confluence.

2.      Performanz

Die kritischen Funktionen müssen möglichst früh umgesetzt werden, sodass diese gemäss den definierten Randbedingungen getestet werden können. Dies betrifft nicht nur die Performanz sondern das grundsätzliche Vorgehen bei einer Entwicklung.

Ist die Performanz ein kritischer Faktor und wird erst am Schluss gemessen, kann es böse Überraschungen geben. Im schlechtesten Fall muss die Architektur angepasst werden, was mit hohen Kosten und Terminverzug verbunden ist.

Software Qualität Verbesserung

3.      Benutzerfreundlichkeit

Jede Anwendung muss ein Logfile haben. Darin protokolliert die Anwendung beispielsweise, auf welche Buttons der Benutzer klickt. Damit kann ein Profil erstellt werden, wo sich der Benutzer wie lange aufgehalten hat und wo nicht.

Die Zielgruppe muss möglichst früh beim Testen involviert werden. Achtung: Die Anwendung muss stabil funktionieren, sonst ärgern sich die die Benutzer.

4.      Zuverlässigkeit

Ein zentraler Punkt für die Zuverlässigkeit ist das Testen der Anwendung. Dazu braucht es:

  • Ein Testkonzept, welches die Grundzüge und Ideen beschreibt. Software können Sie nie zu 100% testen.
  • Testfälle, um mit möglichst wenig Aufwand eine möglichst grosse Abdeckung zu erzielen.

Das Testkonzept und die Testfälle müssen vor Beginn der Umsetzung definiert werden. Sonst kann es passieren, dass Testfälle definiert werden, die nicht getestet werden können. Das kann unter Umständen verheerend sein.

5.      Wartbarkeit

In seltenen Fällen ist eine Anwendung von Anfang an wiederverwendbar und modular. Meist besteht Zeitdruck und der Fokus liegt auf der Funktionalität. Das ist normal. Aus diesem Grund muss Zeit fürs Refactoring eingeplant werden: Der Code wird später so modularisiert, dass die bestehende Funktionalität nicht ändert.

6.      Zusammenfassung

Mit diesen einfachen und kostengünstigen Massnahmen wird die Qualität erheblich gesteigert:

  • Vollständigkeit und Review der Anforderungen
  • Kritische Funktionen möglichst früh umsetzen und testen
  • Benutzer der Zielgruppe müssen möglichst früh mit der Anwendung arbeiten / testen
  • Testkonzept und Testfälle vor Beginn der Umsetzung definieren
  • Regelmässig Zeit fürs Refactoring planen

 

Software-Fehler minimieren

Software-Fehler minimieren will jeder. Nicht jeder Fehler hat die gleichen Auswirkungen auf Kosten und Termine. Ein wichtiger Faktor ist, in welcher Entwicklungsphase der Software-Fehler gefunden wird. Im Grundsatz gilt: Je früher ein Fehler gefunden wird, desto einfacher und günstiger ist dessen Behebung.

Der Teufel im Detail
Der Teufel im Detail

Software-Fehler: V-Modell

Am Beispiel des V-Modells wird klar:  Erkennen Sie einen Fehler während der Systemanforderungsanalyse, hat dies meist keine weitreichenden Konsequenzen. Es braucht Denkarbeit, die Fehlerbehebung geschieht auf Papier. Der Aufwand beträgt einige Stunden.

V-Modell
V-Modell

Ein Software-Fehler bei der Abnahme kann fatal sein. Erfüllen Sie beispielsweise die Anforderungen an die Performance (Antwortzeiten) nicht, sind folgende Schritte nötig:

  • Überarbeitung System-Architektur, System-Entwurf, Software-Architektur
  • Überarbeitung Software-Entwurf (Code anpassen)
  • Durchführen der Tests auf allen Stufen

Projektverzögerung durch Software-Fehler

Ein solcher Software-Fehler kann eine Projekt-Verzögerung von Wochen oder gar Monaten verursachen. Das hat fatale Folgen. Darum lohnt es sich, während den sogenannten Papier-Phasen des Projektes Reviews durchzuführen. Die zusätzliche Zeit, die Sie aufwenden, ist optimal investiert. Dadurch können Sie teure Fehler in späteren Phasen minimieren.

Falls Sie die kritischen Faktoren erst gegen Ende der Entwicklung prüfen können, stellt dies ein erhebliches Risiko dar. Ziel ist es, die kritischen Faktoren möglichst früh zu verifizieren. Dazu gibt es folgende Möglichkeiten:

  • Verwenden Sie ein anderes Entwicklungsmodell (z.B. Scrum). Dies funktioniert nicht von heute auf morgen, da in ihrem Unternehmen das entsprechende Wissen vorhanden sein muss.
  • Realisieren Sie einen Prototyp, der vergleichbar mit der realen Anwendung ist. Dies führt in der Regel zu Mehraufwand.
  • Teilverifizierung in frühen Testphasen (z.B. Integrationstest). Der Mehraufwand ist gering. Sie können nicht das ganze System prüfen.
Software-Fehler minimieren
Software Fehler

Optimale Software-Entwicklung

Für die optimale Software-Entwicklung sind folgende Schritte nötig:

 

  • Frühzeitiger Einbezug der relevanten Personen (je nach Phase verschieden)
  • Durchführung von Reviews
  • Analyse der möglichen Risiken
  • Minimierung gewisser Risiken: nicht jedes Risiko muss minimiert werden, ein Risiko kann bewusst in Kauf genommen werden.

Auf diese Weise können grobe Fehler zwar nicht verhindert, aber grösstenteils minimiert werden.

Weiterführende Links:

Scrum: http://de.wikipedia.org/wiki/Scrum

Review: http://de.wikipedia.org/wiki/Review_(Softwaretest)

IT im KMU – top oder flop?

Gestern ein neuer Release einer Anwendung, heute funktioniert nichts –  diese Erfahrung haben wohl schon viele gemacht – und die IT am liebsten in die Wüste geschickt. Die IT als Kostenfaktor und undurchsichtiges Gebilde? Fehler können nicht vermieden, aber minimiert werden. Voraussetzung ist ein Team aus Fachleuten – IT-Spezialisten,  IT-Generalisten und Business-Verantwortlichen, das mitdenkt, interdisziplinär arbeitet und über den eigenen Tellerrand blickt.

Es ist unbestritten, dass ohne IT nichts mehr läuft und die IT (eine Menge) Geld kostet. Durch die rasante Entwicklung (Stichwort Mobile Geräte) wird es immer schwieriger, den Überblick zu behalten. Grundlegend ist die Kenntnis über den Lebenszyklus einer Anwendung.

Lebenszyklus einer Anwendung

  • Wirtschaftlichkeitsbetrachtung: Was soll die Anwendung tun, welches sind die Hauptfunktionalitäten? Was darf die Anwendung kosten? Daraus werden die einzelnen Anwendungsfälle (Use Cases) abgeleitet.
  • Anforderungsdefinition: Welches sind die Anforderungen an die Anwendung aus Sicht der IT? Ein wesentlicher Schritt ist das ‘Übersetzen’  resp. Transformieren der Business-Anforderungen in IT-Anforderungen. Häufig können aus Kostengründen nicht alle Anforderungen gleichzeitig umgesetzt werden und müssen priorisiert werden.
  • Design: Damit die Anwendung längerfristig rentiert und betrieben werden kann, wird sie in einzelne Bauteile (Komponenten) zerlegt. Die Flexibilität zur Erweiterung der existierenden Bauteile sowie zur Entwicklung neuer Bauteile muss vorhanden sein. Zudem werden die eingesetzten Technologien und Programmiersprachen festgelegt sowie die Schnittstellen definiert. Mit grosser Wahrscheinlichkeit werden für gewisse Funktionalitäten Fremdkomponenten eingesetzt (das Rad muss nicht neu erfunden werden).
  • Entwicklung: Anhand der Design-Vorgaben wird die Anwendung entwickelt.
  • Test: Zuerst werden die einzelnen Komponenten und Subkomponenten  separat getestet. Danach erfolgt der Test auf Anwendungs-Ebene, d.h. es werden die Use Cases aus der Wirtschaftlichkeitsbetrachtung verifiziert.
  • Bereitstellung (Einführung oder Update): Nach erfolgreichen Tests wird die Anwendung bereitgestellt (erstmalige Einführung oder Update).

Je nach Grösse des KMU’s können einzelne Phasen ausgelagert werden (outsourcing).  Die Wirtschaftlichkeitsbetrachtung sowie der Test der Anwendung sollten inhouse gemacht werden: das KMU muss selbst definieren, was die Anwendung tun soll – und dies auch verifizieren.

Fehler frühzeitig vermeiden

Fehler und Fehlerquellen

Fehlerquellen gibt es innerhalb sowie beim Übergang zwischen den einzelnen Phasen. Fehler in den einzelnen Phasen haben unterschiedliche Konsequenzen. Wenn z.B. die Anforderungen falsch oder unvollständig sind, kann das erhebliche Schwierigkeiten zur Folge haben. Wird dies erst in der Testphase bemerkt, muss möglicherweise die gesamte Anwendung umgebaut werden – ein enormer Aufwand mit entsprechenden Kosten. Ein Fehler in der Entwicklung hat meist keinen grösseren Einfluss auf die gesamte Anwendung; vorausgesetzt, das Design ist korrekt.

Zusammenarbeit und Kommunikation

Bei einer Zusammenarbeit mit einem externen Partner ist es wichtig, dass beide Seiten die gleiche Sprache sprechen. Der externe Partner muss genau verstehen, was die Anwendung tun soll. Auf Seite KMU muss jemand das nötige technische Wissen haben, um mit dem externen Partner diskutieren zu können.

Für ein KMU ist es unumgänglich, mindestens einen IT-Generalisten zu haben, der den Lebenszyklus einer Anwendung versteht und mit einem externen Partner zusammen arbeiten kann. Wird die Entwicklung inhouse gemacht, braucht es erfahrene Entwickler, die mitdenken. Es ist nicht möglich, die Vorgaben so genau zu beschreiben, dass kein Interpretationsspielraum besteht.

Um unangenehme Situationen, wie eingangs beschrieben, zu vermeiden, ist es wichtig, dass jedes Teammitglied die Bedürfnisse der anderen versteht. Kommunikation untereinander ist vielfach wichtiger als die verwendeten Technologien.

Zitat Michael Anton: „Ein Programm sollte nicht nur Hand und Fuß, sondern auch Herz und Hirn haben.“