In der Softwareentwicklung versteht man unter Komplexität den Aufwand zum Verstehen eines Programms oder Algorithmus. Daraus folgt, dass der Aufwand für die Neu- oder Weiterentwicklung einer Software nicht nur (je nach Messmethode) von der Anzahl der Elementarprozesse, Datenstrukturen, Datenelemente, usw. abhängig sein kann, sondern auch von der Komplexität. Dabei sind drei Arten der Komplexität zu unterscheiden:
1. Die Komplexität einer Implementierung steht für den Aufwand zum Verstehen der Implementierung (Code und Design) und ist für Abschätzungen des Wartungs- und Weiterentwicklungsaufwands von Bedeutung. Es gibt eine Vielzahl von Metriken, mit denen sich unterschiedliche Aspekte messen lassen:
- zyklomatische Komplexität (McCabe- Metrik)
- lexikalische/textuelle Komplexität (Halstead- Metrik)
- Klassenkomplexität (RfC-Metrik)
Für die Bestimmung des Aufwands neuer Entwicklungsvorhaben ist sie ohne Bedeutung, da sie erst mit der Implementierung entsteht und sich vor allem dadurch auszeichnet, dass unterschiedliche Implementierungen desselben Anwendungsfalls eine unterschiedlich hohe Komplexität haben können. Bei funktionsorientierten Umfangsmessungen spielt sie keine Rolle
2. Die Komplexität der funktionalen Anforderungen bzw. der Anwendungsfälle bestimmt den Aufwand, der zum Verstehen und zur Umsetzung benötigt wird. In die Function-Point-Analyse geht sie in Form von Strukturparametern (z.B. Anzahl der an einem Elementarprozess beteiligten Datenelementtypen und Datenbestände) ein. Die Data-Interaction-Point-Methode bewertet die Komplexität nach der Verwendung von Datenelementen, beispielsweise zur Ein-/Ausgabe, bei Persistenz oder Nur-Lese-Zugriff
3. Alle zum Standard ISO/IEC 14143 konformen funktionsorientierten Messmethoden ignorieren die algorithmische Komplexität der Fachlogik, die in den Prozessen und Funktionen zwischen den Interaktionen des Systems mit den Akteuren bzw. den Zugriffen auf die Datenbank steckt. Sie gehen von einer gegenüber dem funktionalen Umfang nachrangigen Bedeutung der algorithmischen Komplexität aus. Tatsächlich beschränkt sich die Komplexität bei den meisten Systemen auf die Validierung von Eingaben, die Abfrage von Datenbeständen, die Aufbereitung von Ausgaben oder eher einfache logische Operationen und Berechnungen. Da die Anzahl dieser Funktionen oft mit der Anzahl an Interaktionen mit den Akteuren korreliert, ist der dadurch verursachte Fehler vermutlich gering. Dies gilt jedoch nicht für Systeme, bei denen die algorithmische Verarbeitung im Vordergrund steht. Als Beispiel mag ein Routenplanungsprogramm dienen: Input ist eine Start- und eine Zielangabe, Output eine Liste von Streckenabschnitten. Jede funktionsorientierte Metrik würde nur die Interaktionen mit dem Anwender berücksichtigen und einen geringen funktionalen Umfang messen. Da die Entwicklung des ohne Zweifel hochkomplexen Planungsalgorithmus einen hohen Aufwand erfordert, würde man aufgrund des geringen Umfangs auf eine gegenüber anderen Systemen sehr niedrige Produktivität schließen, was nicht korrekt ist.
Aktuell kein praxistauglicher Ausweg
Das Fazit: Funktionsorientierte Messverfahren sind nicht für Systeme mit überdurchschnittlich hoher algorithmischer Komplexität geeignet. Ein praxistauglicher Ausweg existiert bisher allerdings nicht. PASS forscht aktuell in diese Richtung und arbeitet an einer entsprechenden Erweiterung der DIP-Methode. Wie sehen Ihre Lösungsansätze aus
Bildquelle: Shutterstock
