Softwarekomplexität und wie man ihr begegnet

Komplexität, wo bist du?
Kommentare

Software wird in den meisten Fällen von einem dedizierten Team entwickelt. Als Projektleiter tut man gut daran, diese organisatorische Struktur so lange wie möglich stabil zu halten. Eingespielte Teams, die sich in der Performing-Phase [B.W. Tuckman (1965) Developmental sequences in small groups Psychological Bulletin, 63, 384-399] befinden, arbeiten um ein Vielfaches effizienter als neu zusammengewürfelte. 

Sobald in ein solches Team neue Mitarbeiter gebracht werden, sinkt zuallererst die Produktivität der gesamten Gruppe, da Kollegen, die noch nicht firm in der Materie sind, die anderen Kollegen mit Fragen runterbremsen. Diese Einarbeitungsphase so gering wie möglich zu halten, sollte Ziel eines jeden erfolgreichen Softwareprojekts sein. In den meisten Fällen hängt die Dauer dieser Phase von der Komplexität der Anwendung ab. Eine Reduzierung der Komplexität hilft somit dabei, die Produktentwicklung skalierbarer zu machen. Zusätzlich wird eine wenig komplexe Software besser von den Entwicklern angenommen und der Spaß an der Arbeit steigt.

Sicherlich noch wichtiger bei der Betrachtung der Komplexität ist die Wartung und Weiterentwicklung von Software. Je komplexer, umso teurer ist es, neue Features anzubauen. In den Köpfen von vielen Personen, die Software entwickeln, gibt es zwei Grundsätze im Zusammenhang mit Softwarekomplexität:

  • Je größer der funktionale Umfang eines Projekts ist, desto komplexer muss es sein
  • Komplexe Anforderungen benötigen komplexe Lösungen

Um diese Thesen zu widerlegen, muss zuallererst definiert werden, was Komplexität überhaupt ist. Eine mögliche Definition ist folgende:

„Softwarekomplexität beschreibt die Schwierigkeit, Software zu verstehen und zu warten.“

Einigt man sich auf diese Definition, wird schnell klar, dass Komplexität nicht gleichbedeutend mit dem Umfang einer Software ist, es kann sich dabei lediglich um eine der vielen Einflussgrößen handeln. Des Weiteren muss man sich im Klaren darüber sein, dass es nicht die Komplexität einer Software gibt. Je nach Anwender kann dies variieren. Der Kern eines Systems kann maximal komplex gestaltet werden, um dem späteren Plug-in-Entwickler besonders einfache Schnittstellen liefern zu können. Der Kernentwickler schlägt sich in diesem Beispiel mit einer hohen Komplexität herum, der Standardentwickler mit einer niedrigen.

Schön zu sehen an diesem Beispiel, ist, dass Komplexität sich in einem Projekt nicht unbedingt addieren muss. Viele Komponenten bedeuten nicht, dass das Gesamtsystem schwieriger zu verstehen ist, solange die Entkopplung sauber gelöst ist und nicht das Gesamtkonstrukt verstanden werden muss, um Details zu verstehen. Ein System, das durch viele entkoppelte Subsysteme beschrieben wird, sollte die Komplexität des komplexesten Bestandteils erben und nicht die Summe aller. Dank sauberer Entkopplung ist sie für die meisten Aufgaben, die es zu lösen gilt, geringer. 

[header = Der Kampf gegen die Komplexität]

Der Kampf gegen Komplexität ist für einen mittelfristigen Projekterfolg unabdingbar. Um einen Feind bekämpfen zu können, muss man ihn erst einmal finden, doch das ist bei etwas so Allgemeinem wie Komplexität nicht immer einfach. Um die kritischen Stellen in Architektur und Code zu finden, kann man folgende Methoden anwenden:

  • Softwaremetriken
    Eine effiziente Methode, Komplexität zu messen, sind die so genannten Softwaremetriken. Dabei wird über eine mathematische Funktion eine Eigenschaft von Software auf einen Zahlenwert abgebildet der dann verglichen werden kann. Einfache Metriken sind beispielsweise McCabe oder die n-path-Komplexität, die sich auf Funktionen anwenden lassen. Softwaremetriken sind ein guter Indikator für mögliche Schwachstellen. Mathematische Werte müssen aber nicht immer das subjektive Gefühl eines Entwicklers widerspiegeln.
  • Subjektive Bewertung
    Die einfachste Möglichkeit, komplexe Stellen in der Applikation zu finden, ist sicherlich eine Befragung der Teammitglieder. Dabei sollte die Chance genutzt werden, neue Kollegen gleich nach ihrer Einarbeitung zu interviewen. Sobald jemand in ein System eingearbeitet ist, wird er relativ schnell betriebsblind und kann auch komplexe Arbeitsschritte mit geschlossenen Augen beherrschen. Wichtig bei diesem Vorgehen ist, dass man nicht davon ausgehen kann, dass eine Software einfach zu beherrschen ist, nur weil das Kernteam, das die architektonischen Weichen gestellt hat, sie problemlos beherrscht.
  • Messungen
    Wer dem Bauchgefühl der Kollegen nicht vertraut, der kann beispielsweise die Einarbeitungszeit eines neuen Mitarbeiters quantifizieren, indem er die Zeit misst, die er benötigt, um sich in ein konkretes Thema einzuarbeiten. Auch das Lösen einer Standardaufgabe kann zeitlich aufgenommen werden. Dabei sollte man sich vorher überlegen, wie häufig diese Aufgaben durchzuführen und welche Zeiten akzeptabel sind.
  • Drei-Satz-Technik
    Einfache Systeme lassen sich einfach beschreiben. Sollte es einem nicht gelingen, die Arbeitsweise eines Systems in drei Schritten grob zu erläutern, so besteht die Gefahr, dass das System bereits zu komplex ist. Ein Blogsystem könnte wie folgt beschrieben werden:
  1. Der User gibt seinen Beitrag ein
  2. Das System rendert ihn

Jeder dieser Teilschritte kann nun wiederum in maximal drei sinnvolle Unterschritte aufgeteilt werden. Das Wunderbare an diesem Vorgehen ist, dass durch die Beschreibung möglichst vieler Komponenten die Dokumentation des Systems bereits einen großen Schritt weitergeführt wird.

Nachdem die komplexen Bestandteile einer Applikation gefunden wurden, kann man beginnen, sie durch Refactoring und Architekturänderungen zu verbessern.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -