Einschätzung der Codekomplexität in LabVIEW

Zu den wichtigsten Bestandteilen der Projektplanung gehören die Einschätzungen zur Projektdauer, zur Anzahl der benötigten Entwickler und zum Kostenumfang des Projekts. Genaue Einschätzungen tragen dazu bei, dass sich die Chancen auf Projektverzögerungen, Budgetüberziehung und Nichterfüllung der vom Endnutzer festgelegten Anforderungen verringern. Jedoch sind genaue Einschätzungen oft schwer, da in der Anfangsphase eines Projekts gewisse Unsicherheiten bestehen. Damit Einschätzungen genauer werden, werden häufig Softwaremetriken, auch Metriken zur Analyse der Codekomplexität genannt, eingesetzt, um die Größe eines Projekts auszudrücken und berechnen zu können, wie lange bis zur Fertigstellung benötigt wird.

Wird eine Metrik zur Analyse der Codekomplexität lediglich zur Unterstützung benötigt, um LabVIEW-Projekte rechtzeitig und im Rahmen des Budgets zu liefern, kann die Funktion Node Count in LabVIEW als Softwaremetrik genutzt werden. Informationen zum Node Count und über seinen Einsatz zur Einschätzung der Codekomplexität sind in den Abschnitten Metriken zur Analyse der Codekomplexität und Einschätzung für LabVIEW-Projekte verbessern zu finden.

Sollen LabVIEW-Entwicklungen in einen Prozess zur Einschätzung eines Projekts integriert werden, der traditionellere Metriken zur Analyse benötigt, hat National Instruments eine etwa Eins-zu-eins-Beziehung zwischen LabVIEW-Knoten und Source Lines of Code (SLOC) gefunden. Informationen zu SLOC und zur Herleitung dieser Beziehung durch NI sind in den Abschnitten Traditionelle, größenbasierte Metriken zur Analyse der Codekomplexität und Umwandlung von LabVIEW-Knoten in SLOC enthalten.

Das Werkzeug VI Metrics (VI-Metrik), das im LabVIEW Professional Development System (PDS) enthalten ist, stellt Messungen für LabVIEW-Code bereit. Mit diesem Werkzeug ist es möglich, die Anzahl an LabVIEW-Knoten zu zählen, die innerhalb eines VIs oder einer Hierarchie von VIs genutzt werden. Ein Knoten ist dabei fast jedes Objekt auf dem Blockdiagramm, u. a. Funktionen, VIs und Strukturen wie z. B. Schleifen und Sequenzen. Nicht dazu gehören allerdings Beschriftungen und Grafiken. Programmknoten entsprechen also den Statements, Operatoren, Funktionen und Unterprogrammen in textbasierten Programmiersprachen. Ähnlich vielen traditionellen Softwaremetriken, die auf textbasierte Programmiersprachen angewandt werden, ist die Knotenanzahl ein auf der Größe basierendes Maß, das zur Einschätzung der Softwarekomplexität genutzt werden kann.

In LabVIEW PDS kann das Werkzeug VI Metrics durch Auswahl des Pfads Tools » Advanced » VI Metrics... gestartet werden. Dieses Werkzeug stellt noch weitere Angaben bereit, wie etwa die Anzahl der globalen und lokalen Schreib- und Lesevorgänge und die Zahl der Diagramme. Abbildung 1 zeigt das Fenster VI Metrics für ein VI namens Memory Monitor. In diesem Beispiel zeigt VI Metrics die Gesamtzahl der Knoten in der gesamten Hierarchie von VIs an sowie die Zahl der Knoten in jedem einzelnen VI.

Abb. 1: Das Fenster VI Metrics zeigt etliche Statistiken an, darunter die Nutzung von Knoten.

Will ein Anwender die Genauigkeit und Zuverlässigkeit seiner Einschätzungen zur Dauer und zu den Anforderungen von LabVIEW-Projekten verbessern, legt aber keinen Wert auf eine Umwandlung der Komplexitätsmetriken in ein textbasiertes Pendant, kann er einfach eine entsprechende LabVIEW-Metrik wählen. Der LabVIEW-Knoten ist die von National Instruments empfohlene Softwaremaßzahl.

Allerdings ist die Auswahl einer LabVIEW-Metrik nur der erste Schritt zur Verbesserung der Einschätzungen für LabVIEW-Projekte. Damit dieser Ansatz funktioniert, muss eine Sammlung mit Informationen zu gegenwärtigen und bisherigen Projekten erstellt werden. Mithilfe dieser historischen Daten kann der Anwender berechnen, wie viel Zeit zur Entwicklung einzelner Komponenten in bestehenden Systemen benötigt wurde. Anschließend setzt er diese Informationen mit der Anzahl der Knoten in dieser Komponente in Beziehung. Allerdings sind vor der Einschätzung der für ein neues Projekt erforderlichen Knoten einige Schritte abzuarbeiten.

1. Ein neues Projekt sollte in Unterprojekte aufgeteilt werden, die mit Aufgaben verglichen werden können, welche in der Vergangenheit ausgeführt wurden. Nach einer Aufteilung in Unterprojekte ist die Einschätzung der für jedes Unterprojekt erforderlichen Zeit leichter.
   
2. Es sollten Angaben zum Kenntnisstand der Programmier enthalten sein, wenn die Zeit bis zur Fertigstellung eines Unterprojekts eingeschätzt wird. LabVIEW ist zwar ein sehr leistungsfähiges Entwicklungswerkzeug, doch wirkt sich der Kenntnisstand immer noch auf die Produktivität des Einzelnen und die Codeeffizienz aus.
   
3. Es sollten, wann immer möglich, Richtlinien für einen konsistenten Stil des LabVIEW-Codes eingehalten werden. Die Anwendung einer größenbasierten Komplexitätsmetrik wie etwa die Knotenanzahl kann problematisch sein, wenn von verschiedenen Entwicklern oder Entwicklergruppen unterschiedliche Entwicklungsansätze verwendet werden.
   
4. Der Programmcode sollte zur Optimierung der Effizienz geprüft und dabei auf robuste Entwürfe Wert gelegt werden. Nicht alle Knoten werden mit demselben Qualitätsniveau erstellt und häufig können zwei VIs dieselbe Aufgabe erfüllen, selbst wenn eines davon viel weniger Knoten enthält.
   

Im Bereich der textbasierten Programmiersprachen ist eine gängige Metrik zur Analyse der Codekomplexität als Source Lines of Code (SLOC) bekannt. SLOC wird zur Beschreibung der Programmcodegröße verwendet, was zur Berechnung der Projektdauer bis zu seiner Fertigstellung und der Projektkosten genutzt werden kann. Zudem kann damit auch die Produktivität gemessen werden, sobald die Software fertiggestellt wurde. SLOC ist zum einen deshalb so beliebt, da es sich einfach ermitteln lässt. In C wird ein SLOC gewöhnlich als die Zeile des Programmcodes definiert, die mit einem Semikolon endet (d. h. eine vom Anwender erstellte Codezeile, bei der es sich nicht um einen Kommentar oder um eine leere Zeile handelt). Viele Anbieter vertreiben Werkzeuge, die SLOC für jede beliebige Quelldatei berechnen. Da Programmiermethoden innerhalb eines Unternehmens normalerweise standardisiert sind, erstellen Firmen, die SLOC nutzen, gewöhnlich eine Datenbank mit Informationen zu Projekten, um ihre Einschätzungen zu verbessern.

Die grafische Programmierung stellt offensichtlich eine Herausforderung für alle mit der Einschätzung eines Projekts betrauten Mitarbeiter dar, die mit SLOC vertraut sind. Eine vergleichbare LabVIEW-Metrik zur Analyse der Codekomplexität, wie z. B. die Knotenanzahl, muss für die Entwicklung mit LabVIEW in SLOC übersetzt werden, damit sie in die in vielen Unternehmen bestehende Verfahren zur Projekteinschätzung integriert werden kann.

Teil zweier Softwareentwicklungsprojekte bei National Instruments war kürzlich die Erstellung äquivalenter Software in LabVIEW und C. Das erste Projekt war die Entwicklung der NI-DAQmx-Programmierschnittstellen für LabVIEW und LabWindows/CVI, die ANSI-C-basierte Entwicklungsumgebung von National Instruments. Das zweite Projekt umfasste die Neugestaltung der LabVIEW- und LabWindows/CVI-Benutzeroberflächen für die Testmanagementsoftware NI TestStand. Nach Abschluss beider Projekte verglich National Instruments die Anzahl der verwendeten LabVIEW-Knoten mit dem entsprechenden SLOC in C. Dabei wurde festgestellt, dass in etwa ein Eins-zu-eins-Verhältnis zwischen LabVIEW-Knoten und SLOC bestand.

Allerdings ist jede Umwandlung einer LabVIEW-Metrik in SLOC ungenau, da nämlich größenbasierte Metriken zur Analyse der Codekomplexität von der verwendeten Programmiersprache abhängen. So können beispielsweise Anweisungen in einer höheren Programmiersprache wie beispielsweise C mehr Funktionalität bereitstellen als jene in einer maschinennäheren Sprache wie der Assembler-Sprache. LabVIEW-Entwickler bringen unterschiedliche Erfahrungsniveaus und Kodierungsstile mit, welche die Entwicklung einer Anwendung beeinflussen können. LabVIEW ist gemeinhin produktiver als andere Entwicklungsumgebungen, weshalb jede Korrelation eine Annäherung zwischen LabVIEW-Knoten und SLOC darstellt.

Neben dem Konzept der LabVIEW-Knoten gibt es eine weitere Methode, die manche LabVIEW-Entwickler zur Übersetzung von LabVIEW-Metrik zur Analyse von Codekomplexität in entsprechende SLOC genutzt haben. Dabei verglichen die Entwickler die Größe des LabVIEW-Codes auf der Festplatte mit dem Platzbedarf einer entsprechenden C-Objektdatei. Sind die SLOC, die zur Erstellung der C-Objektdatei verwendet wurden, bekannt, kann LabVIEW-Code in SLOC umgewandelt werden. In LabVIEW ist eine Einsicht in die Speichernutzung eines VIs über den Pfad File » VI Properties » Memory Usage, möglich (siehe Abbildung 2).

Abb. 2: Die Kategorie Memory Usage im Dialogfeld VI Properties zeigt die Größe dieses Programmcodes auf der Festplatte: 10,0 K

Hinweis: Die Funktion Memory Usage zeigt nicht nur die Größe des LabVIEW-Codes auf der Festplatte, sondern auch den Speicherplatz, der von Frontpanel- und Blockdiagrammobjekten und den im VI gespeicherten Daten genutzt wird. Wird diese Methode zur Umwandlung von LabVIEW-Komplexität in entsprechende SLOC eingesetzt, sollte nur der zum Programmcode gehörende Speicherplatz mit eingeschlossen werden.

Hinweis: Bei National Instruments wurde diese Methode zur SLOC-Umwandlung während der Softwareentwicklung nicht verwendet. Daher können keine Informationen über einen Umrechnungsfaktor von LabVIEW-Codegröße in entsprechende SLOC bereitgestellt werden.

Obgleich es sich bei LabVIEW um eine grafische Entwicklungsumgebung handelt, können Entwickler immer noch Metriken zur Analyse der Codekomplexität, wie z. B. die LabVIEW-Knotenanzahl, verwenden, um die Zeit und den Aufwand zu bewerten, die zur Fertigstellung früherer Projekte benötigt wurden und daraus Richtwerte für zukünftige Entwicklungen gewinnen. Zwar ist die Beziehung zwischen einem einzelnen LabVIEW-Knoten und einer textbasierten Programmcodezeile nicht perfekt abgestimmt, doch hat National Instruments das Verhältnis eines LabVIEW-Knotens zu einer SLOC durch interne Studien von Projekten herausgefunden, die gleichwertigen LabVIEW- und C-Code umfassten. Um die Ergebnisse von Projekteinschätzungen zu verbessern, sollten Entwickler die LabVIEW-Metriken über mehrere Projekte hinweg verfolgen und dazu die Projekte in kleinere Bestandteile unterteilen. Zudem sollten wichtige Faktoren wie Programmiererfahrungen der einzelnen Entwickler sowie die Art des Programmcodes erfasst werden.

Hauptseite NI LabVIEW

Webcast: LabVIEW – Neue Funktionen der grafischen Entwicklungsumgebung