Daten- und Software-Analyse für die Konzeption von IT-Lösungen

Die Anforderungsanalyse ist einer der ersten Schritte zur Bewertung einer augenblicklichen Ist-Situation und zur systematischen Aufstellung aller Forderungen und Wünsche, die mit einer Änderung am Ist-Zustand oder mit der Erstellung eines (Software-) Systems erfüllt werden sollen.

Die Analyse beinhaltet:

• eine Sammlung der Forderungen,
• deren Kategorisierung sowie
• eine Prüfung und Bewertung.

Da die Analyse eine Grundlage für die weiteren Planungen eines Projektes sind, haben deren Ergebnisse eine besondere Bedeutung. Während der Analyse nicht erfasste Forderungen können später immer nur mit einem Mehraufwand umgesetzt werden.

Die Anforderungen müssen:

• alle benannt werden, es darf keine indirekten Forderungen geben
• eindeutig definiert und begrenzt werden
• verständlich beschrieben werden. Ein Auftragnehmer muss die schriftlichen Forderungen ohne zusätzliche Erklärungen verstehen können.
• einzeln identifizierbar sein, z.B. über eine lfd. Nummer, damit später u.a. die Erfüllung der Forderungen eindeutig erfolgen kann
• jede für sich nach einem einheitlichen Schema dokumentiert werden
• unter Berücksichtigung gesetzlicher Vorgaben erstellt werden
• nachprüfbar sein, d.h., mit konkreten Abnahmekriterien verbunden sein
• untereinander widerspruchsfrei beschrieben werden.

Es muss eindeutig beschrieben werden,

• welche Abhängigkeiten zwischen den Forderungen bestehen
• welche Forderungen nur gemeinsam umgesetzt werden können
• worin die Forderungen begründet sind (fachlich und technisch oder nur fachlich bzw. nur technisch)
• welche Benutzergruppe die Forderungen stellt.

Aus der Bewertung muss ersichtlich sein,

• ob die Forderungen in sich widerspruchsfrei sind,
• die Forderungen machbar sind,
• welche Priorität jede Forderung hat.

Die Analyseergebnisse können in Listenform oder nach einer Datenauswertung auch grafisch dargestellt werden.
Sie sind dann Grundlage für die Erstellung eines Lasten- und Pflichtenheftes.
Anforderungsanalyse in der Phase der Projekt-Definition
Informationen zur Implementierung von Software

In Mind Maps werden einzelne Gedanken zu einem Thema in grafischer Form in einer übersichtlichen Baumstruktur dargestellt. Das zentrale Thema wird dabei in der Mitte der Darstellung angeordnet. Weitere Gedanken können farblich gekennzeichnet um das Zentrum angeordnet und mittels Verknüpfungspfeilen zueinander in Verbindung gebracht werden.

Zu jedem einzelnen Gedanken werden lediglich Stichpunkte und keine ausführlichen Erläuterungen dargestellt. Mit einer Mind Map ist es somit möglich, ein Thema, damit verbundene Unterthemen und deren Abhängigkeiten in der Übersicht strukturiert darzustellen.
Zu einem Arbeitsbereich kann z.B. ein ersten Überblick geschaffen werden, in einer Diskussionsrunde können Vorschläge gesammelt oder Anforderungen und Wünsche an ein zu erstellendes (Software-) System dargestellt werden.
Eine Mind Map kann eine Grundlage zur Erstellung weiterer vertiefenderer Arbeitsdokumente sein.

Projektdurchführung (farbliche Kennzeichnungen in Moderationskarten)
Beispiel einer Mind Map

Die Modellierung einer Software wird durchgeführt, um die Effizienz des Software-Entwicklungsprozesses zu erhöhen. Von der Object Management Group (OMG) wurde dazu eine standardisierte Sprache entwickelt, die Unified Modeling Language.
Die UML wird in der (Objekt-orientierten) Software-Modellierung eingesetzt, kann jedoch auch in anderen Branchen angewendet werden.

• Ziel des UML-Einsatzes ist es, die Implementierung der Software (möglichst) erst dann zu beginnen, wenn die Planung der Implementierung beendet ist. Eine Änderung am Modell ist wesentlich weniger zeitaufwändig als die fortwährende Änderung der Software-Sourcen.
• Die Verwendung von UML-Modellen ist jedoch auch für die Erweiterung bestehender Software sehr sinnvoll. Mit der ständig steigenden Komplexität der Software ist es immer schwieriger, anhand der Software-Sourcen einen Überblick über die Funktionalität der Software zu erhalten.
• Die Planung von Erweiterungen mittels überschaubarer grafischer Modelle ist wesentlich einfacher und setzt nicht unbedingt die Kenntnis der konkreten Programmiersprache voraus, in welcher die Software implementiert wird.

Die mit dem Projekt beabsichtigten Ziele werden häufig von Mitarbeitern verschiedenster Spezialisierungsrichtungen geplant (Fachseite des Auftraggebers, Auftragnehmer, Informatiker, Betriebswirte usw.). Häufig ist es wegen der Komplexität der Abläufe so, dass Kenntnisse zu den jeweils anderen Fachrichtungen nur in begrenztem Umfang vorhanden sind. UML-Modelle bieten hier eine Art Schnittstelle zwischen den Bereichen.

• Ein Analytiker eines Consulting-Unternehmens erstellt ein Anwendungsfall-Diagramm, welches nachfolgend von der Fachseite beurteilt wird.
• Der Auftraggeber einer Branche stellt die Reihenfolge von Arbeitsschritten in Aktivitätsdiagramme dar. Der Informatiker erstellt daraus Software, in welcher die Einhaltung dieser Arbeitsschritte geprüft und gesteuert wird.
• Der Betreiber eines Online-Shops legt in einem Zustands-Diagramm fest, unter welchen Voraussetzungen Bestellungen vorgenommen werden können. Der Informatiker erstellt eine Software, die nur diesen Ablauf von Bestellungen ermöglicht.

Mit der UML sind verschiedene Aspekte und Zusammenhänge der Software mit 13 Diagrammtypen darstellbar:

Struktur-Diagramme:

• Klassendiagramm
• Kompositions- Strukturdiagramm (Montagediagramm)
• Komponentendiagramm Beispiel
• Verteilungsdiagramm
• Objektdiagramm
• Paketdiagramm

Verhaltens-Diagramme:

• Aktivitätsdiagramm Beispiel
• Anwendungsfalldiagramm (Use-Case oder Nutzfalldiagramm) Beispiel
• Interaktionsübersichtsdiagramm
• Kommunikationsdiagramm
• Sequenzdiagramm
• Zeitverlaufsdiagramm
• Zustandsdiagramm

In der UML ist eine Notation für die grafische Darstellung vereinbart. Die einzelnen Diagrammtypen sind jedoch nicht strikt voneinander getrennt, die grafischen Elemente können daher auch in Diagrammtypen verwendet werden, für die sie ursprünglich nicht vorgesehen sind. UML-Notation (bzw. auch Linksammlung - Softwareentwicklung)

Für die Erstellung der Diagramme sind eine Reihe von (kostenpflichtigen) Tools verfügbar:
Übersicht unter: Linksammlung - Softwareentwicklung

Diese Tools ermöglichen das Speichern der Modelle unter verschiedenen Dateiformaten (html, Grafiken usw.).
Für die Weitergabe der Modelle zwischen den Tools kann die XMI-Sprache (XML Metadata Interchange) verwendet werden, sofern die Tools diese Möglichkeit bieten.
Die direkte Generierung von Software aus den UML-Modellen für eine konkrete Programmiersprache ist nur unter strikter Einhaltung von Definitionsvorgaben begrenzt möglich.

Ausbaustufen der Tools:

• 1.Gruppe (UML-Versionen 1.x): diese Tools speichern die grafischen Elemente auf den Diagrammen nicht zentral. Abhängigkeiten zwischen den Beschreibungen der Modell-Bestandteile können mit den Tools nicht geprüft werden.
• 2.Gruppe (UML-Versionen 2.x): diese Tools bieten mehr Möglichkeiten, da sie alle grafischen Elemente zentral in einem Repository speichern. Mit den Tools sind Konsistenzprüfungen innerhalb des Modells möglich.

In der zunehmend digitalisierten Welt werden eine Unmenge von Daten gespeichert und verarbeitet. In der Praxis bedeutet dies auch, dass eine unüberschaubare Anzahl von Informationen automatisch gemessen und aus den Daten Schlussfolgerungen für weitere Aktivitäten abgeleitet werden. Bedingt durch den Datenumfang und die Geschwindigkeit, mit der dieser Prozess abläuft, ist es praktisch unmöglich, diese Informationen vollständig manuell auf ihre Gültigkeit zu prüfen.
Da die aus den Daten gezogenen Schlussfolgerungen zumeist weitreichende Folgen nach sich ziehen können, hat die automatisierte Prüfung von Informationen und die Feststellung von Abweichungen, z.B. für die Qualitätssicherung, eine besondere Bedeutung.
Für die Prüfung von Messwerten können Prüfverfahren angewendet werden, welche Wahrscheinlichkeits-Verteilungen verwenden. Somit ist es z.B. leicht möglich, bekannte Parameter wie Werte-Grenzen und Mittelwerte zu ermitteln. Häufig werden jedoch auch Auskünfte darüber benötigt, ob sich wichtige Werte tendenziell verändern oder Abweichungen, z.B. von den üblichen Zahlen-Häufigkeiten, vorhanden sind.

• die Prüfung der Daten-Gültigkeit (z.B. Qualitätssicherung)
• die Ermittlung von Tendenzen (z.B. Wirksamkeit von Medikamenten)
• die Erkennung von Manipulationen (z.B. Bestell- und Rechnungswesen, Steuern, bei Glücksspielen: Prüfung, ob Würfel manipuliert wurden, indem auf eine Normalverteilung der gewürfelten Zahlen geprüft wird)
• die Prüfung von Planungswerten auf Machbarkeit und branchenübliche Werte
• die Ermittlung des Kunden-Verhaltens (z.B. Ablehnung oder Zustimmung zur Produktveränderung)
• Auswertung vorhandener Daten zur Schaffung von Planungswerten
• Aufdeckung von (Software-) Systemfehlern
• ... Sie können aber auch einfach nur Ihre Lieblingsziffer ermitteln ...

Statistische Verfahren werden zunehmend auch angewendet, um Manipulationen an den Daten aufzudecken.

Typische Anwendungsfälle sind z.B.:

• die Überprüfung von Daten aus der Buchhaltung (Bestellungen, Rechnungen, Bilanzen)
• Überprüfung von Kassen-Aufzeichnungen im Handel
• die Prüfung von Fahrtenbüchern
• die Prüfung von Forschungsergebnissen auf Manipulationen
• die Ermittlung von Rechnungs-Splittungen, die das Ziel haben, Unterschriftsgrenzen zu unterschreiten
• die Prüfung von Umsatzsteuer-Beträgen
• die Prüfung, ob der Rohstoffeinsatz zum Betriebsergebnis lt. Buchhaltung stimmig sein kann
• die Prüfung von Planungs-Zahlen hinsichtlich branchenüblicher Größenordnungen
• die Prüfung von (Einkommen-) Steuermeldungen

Durch statistische Verfahren bekanntgewordene Manipulationen sind z.B.:

• der Enron-Skandal im Jahr 2001
• der Worldcom-Skandal im Jahr 2002
• siehe auch: Artikel in Financial Times Deutschland vom 20.03.08:

• Sie können automatisiert und auch auf große Datenmengen angewendet werden. Der Zeitbedarf dazu ist im Vergleich zu einer manuellen Prüfung minimal.
• Zur Auswertung muss nicht die Enstehung der Daten mit einem großen Aufwand geprüft werden. Stattdessen genügt es, relativ wenige Daten auszuwerten. Es werden somit z.B. nicht einzelne Rechnungsformulare geprüft, sondern nur der Rechnungsbeträge.
• Die Auswertung von Unternehmensdaten durch behördliche Einrichtungen ist sehr leicht durchzuführen, da z.B. per Gesetz die Verpflichtung zur elektronischen Bereitstellung von Daten aus der Buchhaltung besteht.
• Ohne Kenntnis darüber, wie die ausgewerteten Daten entstanden sind, können mit einer hohen Sicherheit, häufig zu 95%, Aussagen dazu getroffen werden, ob diese Daten gültig sind bzw. manipuliert wurden.

• Trotz einer hohen Sicherheit (häufig 95%) der Aussagen sind diese immer mit einer gewissen Unsicherheit (häufig 5%) verbunden.
• Diese Verfahren werden häufig nur im Zusammenhang mit der Aufdeckung von Manipulationen erwähnt und von den Steuerbehörden sicher auch vorwiegend in diesem Sinne verwendet. Die Anwendung für diese Zwecke stellt jedoch nur einen äußerst geringen Teil der möglichen Einsatzbereiche statistischer Verfahren dar.
• Nicht jeder Abweichung von den erwarteten Ergebnissen stellt eine Manipulation dar. Nach der Durchführung statistischer Prüfungen sind die Erkenntnisse aus diesen Prüfungen immer im Zusammenhang dazu zu bewerten, wie die ausgewerteten Daten entstanden sind.
• Statistische Verfahren liefern z.T. "nur" Aussagen über die Gesamtheit der Daten und nicht über einen einzelnen Wert.
• Die Anwendung statistischer Verfahren und im Bedarfsfall deren manuelle Nachprüfung setzen ein vertieftes mathematisches Verständnis voraus. Es besteht zunehmend das Problem, dass Bürger mit den Ergebnissen statistischer Verfahren konfrontiert werden und auch entsprechende Folgen tragen müssen, ohne dass der zweifelfreie Nachweis erbracht wird (und auch nicht erbracht werden kann), dass der Bürger an den Daten Manipulationen vorgenommen hat. Erschwerend ist, dass zum Verständnis der statistischen Ergebnisse die Kenntnis mathematischen Zusammenhänge zwingend erforderlich ist (z.B.: Wahrscheinlichkeits- Verteilungen, Signifikanzniveaus, Logarithmus-Funktionen usw.)

Die Ergebnisse statistischer Verfahren beruhen auf Aussagen über die Zahlen-Wahrscheinlichkeiten, z.B.: einer Abweichung von einem Durchschnitt, dem Vorhandensein oder Fehlen von Werten, dem Unter-/Überschreiten von Grenzwerten. Aus diesem Grund wird vor der Durchführung statistischer Prüfungen eine so genannte Null-Hypothese aufgestellt und zugleich festgelegt, mit welcher Genauigkeit (d.h. Signifikanzniveau, Irrtumswahrscheinlichkeit) die Prüfungen durchgeführt werden sollen.
Die Tabellen der Wahrscheinlichkeitsfunktionen enthalten die Aussage, mit welcher Wahrscheinlichkeit ein Messwert bei einer zuvor festgelegten Genauigkeit auftreten kann.
Bei den Prüfungen können zwar 100% der Daten berücksichtigt werden, eine statistische Aussage, z.B. zur Gültigkeit oder zu einer Manipulation, kann dennoch nicht mit 100%iger Genauigkeit getroffen werden.
In Praxis wird häufig davon ausgegangen, dass bei einer statistischen Sicherheit von 95% Abweichungen der Zahlen vom erwarteten statistischen Ergebnis nicht mehr zufällig sein können.
Die Genauigkeit der Aussagen wird auch wesentlich durch den Umfang der ausgewerteten Daten beeinflusst.

• Einige Prüfungen sind nur auf bestimmte Zahlenbereiche sinnvoll anwendbar: z.B. Benford-Gesetz auf die ersten Ziffern einer Zahl, Chi-Quadrat-Test eben nicht auf diese, sondern nur auf die unmittelbaren Vor- und Nachkommastellen.
• Der Chi-Quadrat-Test liefert nur für große Datenmengen sichere Ergebnisse.
• Bei kleinen Datenmengen kann stattdessen der Kolmogorow-Smirnow-Test angewendet werden, er liefert jedoch nicht so sichere Ergebnisse wie der Chi-Quadrat-Test.
• Bei der wohl bekanntesten Wahrscheinlichkeitsverteilung, der Gauß'schen Standard-Normalverteilung, gilt, dass die Kurve der Verteilungsfunktion nie die x-Achse schneiden kann. Vereinfacht gesagt: unabhängig davon, mit welcher Sicherheit die Aussage getroffen werden soll, es bleibt immer ein Rest Unsicherheit vorhanden.
• Die Prüfung eines gesamten vorhandenen Datenbestandes mit einer hohen Sicherheit ist aus Zeit- und Kostengründen selten möglich. Stattdessen werden Stichproben verwendet. Um sicher zu stellen, dass die Auswertung der Stichproben eine relevante Aussage über den ganzen Datenbestand liefern, werden Mindest-Anzahlen an Werten ermittelt, die in einer Stichprobe vorhanden sein müssen. Bei dieser Ermittlung wird von vornherein von einer Fehlerunsicherheit (tolerierter Fehler) ausgegangen.
• Ebenso wie zu kleine Datenmengen können auch zu viele Daten eine Ursache für unsichere Aussagen sein: Zahlen-Ausreißer unter vielen Daten verändern z.B. den Mittelwert kaum. Es ist somit nicht zutreffend, dass ein großer Umfang an auszuwertenden Daten auch eine große Sicherheit der Aussagen gewährleistet.

• Die ermittelten Ergebnisse sind (fast) immer mit einem Unsicherheitsfaktor verbunden. Aus den vorhandenen Daten kann selten eine zu 100% zutreffende Schlussfolgerung gezogen werden. Diese Unsicherheit wird häufig mit einer Wahrscheinlichkeit (einem Signifikanz-Niveau) für das Zutreffen oder die Ablehnung einer zuvor vermuteten Annahme dargestellt.
• Die aus den Daten gewonnenen Ergebnisse sind immer im Zusammenhang mit der Herkunft der Daten zu verwenden. Eine besondere Häufung von 99-Cent-Beträgen im Handel ist sicher normal, eine Häufung von Bestellungen mit Beträgen kurz unter dem Betrag, ab dem der Vorgesetzte zustimmen muss, ist sicher auffällig.
• Für statistische Auswertungen muss häufig eine Mindest-Anzahl von Daten vorhanden sein, damit die Ergebnisse überhaupt aussagekräftig sind.
• Zu viele Daten können andererseits auch dazu führen, dass einzelne Abweichungen und Tendenzen unerkannt bleiben.
• Das Vorhandensein oder das Fehlen von Abhängigkeiten der Daten untereinander kann entscheidend dafür sein, welches Prüfverfahren angewendet werden kann.

• mathematische Gesetze, u.a. zu Zahlen-Verteilungen
• Zeitreihen-Vergleiche
• die Verwendung gewohnheitsmäßiger oder branchenüblicher Werte-Größen
• die Erkenntnis, dass jede Person unbewusst seine Lieblingszahlen verwendet
• das Wissen darüber, dass in Praxis eine 100%-ige Übereinstimmung von Datenkonstellationen mit theoretischen Werten fast nicht vorkommt

Unter dem Menüpunkt Statistik-Prüfung ist ein von mir erstelltes Programm beschrieben, mit welchem Zahlenhäufungen und Manipulationen in Daten ermittelt werden können.

Die Daten prüfe ich entsprechend folgender Gesetzmäßigkeiten:

• Verteilung der 1. sowie 1.+2. führenden Ziffer lt. Benfordscher Verteilung
• Verteilung der 1. sowie 1.+2. Vorkomma-Stelle lt. Chi-Quadrat-Verteilung
• Verteilung der 1. sowie 1.+2. Nachkomma-Stelle lt. Chi-Quadrat-Verteilung
• Normal-Verteilung

Statistik beim Finanzamt (FA)

• Die Anwendung statistischer Verfahren durch das FA ist per Gerichtsbeschluss seit 1989 zulässig.
  BGH Urteil v. 14.12.1989, Az 419/89
  Urteil Finanzgericht Münster v. 10.11.2003, Az. 6 V 4562/03
• Das FA wendet (u.a.) das Programm WinIdea (Interactiv Data Extraction and Analysis) zur Prüfung von Steuerdaten an, in welchem (u.a.) die Benford- und Chi-Quadrat-Verteilung zur Datenprüfung verwendet werden.
  Auf der Homepage des Idea-Herstellers (siehe Link, Seite 2) verspricht der Hersteller eine 100-ige Prüfung der Daten und ein 100%-iges Ergebnis. Aus rein mathematischer Sicht war hier sicher der Wunsch der Vater des Gedanken, denn aus der Sicht mathematisch-statistischer Verfahren kann es kein derart sicheres Ergebnis geben, da die Aussagekraft Statistischer Prüfungen immer auch von der Anzahl der ausgewerteten Daten abhängig ist.
  Veröffentlichung auf www.avendata.de
• Seit dem Jahr 2001 haben Steuerbehörden das Recht auf die direkte Einsichtnahme oder Überlassung von Steuer-Daten der Steuerpflichtigen. Die Grundlage dafür sind die seit 2001 gültigen Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU). (Quelle: www.bundesfinanzministerium.de, Veröffentlichungen zu Steuerarten - GDPdU)
• Falls Sie Ihre Steuerdaten per ELSTER-Software elektronisch an das FA melden, sind Sie gegenüber dem FA sehr hilfreich. Wenn Sie Ihre Daten (ohnehin) nicht manipuliert haben, so sind Sie aufgrund der Statistischen Unsicherheit trotzdem nicht vor den Ergebnissen der Statistischen Auswertung sicher!
• Sofern die Gültigkeit Ihrer Steuerdaten aufgrund der Statistischen Auswertungen angezweifelt wird, darf das FA Ihr Einkommen schätzen und Ihre Steuerlast danach bemessen. Ggf. wird das FA eine Außenprüfung bei Ihnen vornehmen und dann auch weitere Steuer-Angaben prüfen.
• Sofern Sie Ihre Daten (ohnehin) unverändert belassen haben: Falls die Statistischen Auswertungen eine Abweichung anzeigen, ist von einer Anpassung der Daten an die statistisch erwarteten Werte abzuraten. Daten, die zu sehr den Gesetzmäßigkeiten entsprechen, sind erst recht auffällig. Stattdessen gilt: statistische Auswertungen sind immer im Zusammenhang mit der Datenherkunft zu bewerten!

Neben der Neu-Entwicklung von Software erlangt die Erweiterung und Anpassung bereits bestehender Software-Module im Rahmen von Wartungsarbeiten eine immer größere Bedeutung. Für eine möglichst realistische Anforderungsanalyse in der Phase der Projekt-Definition ist es erforderlich, den Aufwand für Änderungen an bereits vorhandener Software gut einzuschätzen.
Optimal wäre es, wenn die Spezialisten (Fachseite und Informatiker), welche die Software ursprünglich erstellt haben, diese Aufgabe übernehmen können. Dieser Situation ist jedoch immer seltener vorhanden, da diese Mitarbeiter aus den unterschiedlichen Gründen meist nicht mehr dafür verfügbar sind.
Andererseits ist es häufig so, das Mitarbeiter, die in der Projektplanung tätig sind, nicht über die Zeit bzw. die Fachkenntnis verfügen, um sich vorhandene Softwaremodule anzusehen und zu bewerten.
Für die Projektplanung wäre es somit optimal, wenn die Bewertung von Software automatisiert, ohne Kenntnis der konkreten Programmiersprache und mit einem geringem Zeitaufwand vorgenommen werden kann.

Erschwerend für die Bewertung ist, dass

• die vorhandenen Programmiersprachen zur Programmierung der gleicher Aufgabe unterschiedlichste Möglichkeiten bieten
• die Gestaltung eines Source-Codes (Modularisierung, Kommentierung, Namensvergabe für Variablen usw.) stark von den persönlichen Vorlieben des Programmierers geprägt ist
• Programmbefehle und Kommentare z.T. in beliebiger Reihenfolge und auch ineinander geschachtelt angeordnet sein können.
• die Bewertung stark vom subjektiven Empfinden und der Fachkenntnis der Person abhängig ist, welche die Software bewertet.

Optimal für die Software-Bewertung wäre es, wenn Eigenschaften der Source, wie z.B. Anzahl von Variablen, gemessen werden könnten und somit subjektive Bewertungen nicht mehr entscheidend für die Einstufung des Wartungsaufwandes an der Software sind.

Zur Einschätzung des Änderungsaufwandes wäre es gut, Kenntnis zu folgenden Punkten zu haben:

• Wie gut ist die Software dokumentiert (Anzahl der Kommentar- und Programmzeilen)?
  In der Praxis hat sich ein Kommentar-Anteil von 30-75% am Source-Code bewährt. Bei weniger als 30% Kommentaren kann von einer mäßigen Kommentierung ausgegangen werden. Ein Mitarbeiter, der den Source-Code nicht kennt, hat dann sicher einen größeren Aufwand, um den Source-Code zu verstehen. Bei über 75% Kommentaranteil wurde die Dokumentation im Sourcecode stark überbetont. In diesem Fall liegt dann eher ein beschreibendes Dokument vor als eine Programm-Source. Davon unabhängig dürften die übermäßig vielen Kommentarzeilen das Programmverständnis erschweren.
• Wie komplex ist der Source-Code?
  Die Komplexität ist dadurch bestimmt, wieviele Elemente der Programmiersprache und wieviele selbst definierte Programm-Variablen verwendet wurden. Dabei ist die Summe der überhaupt verwendeten Elemente zu berücksichtigen und die Häufigkeit, mit der sie im Source vorkommen. Die Verwendung einer Variable, die nur selten im Programm vorkommt, ist sicher weniger anfällig für Fehler, als eine häufig verwendete Variable.
• Wie viele Entscheidungswege, z.B. IF-Abfragen, gibt es im Source-Modul?
• Wie viele Programmzeilen (Lines of Code) sind vorhanden?

Für die Bewertung werden Software-Metriken verwendet, mit welcher Software-Einheiten als Zahlenwert dargestellt werden können. Diese Metriken sind ein Mittel, um die Sourcen möglichst objektiv und an hand von praktischen Erfahrungswerten u.a. zur Wartbarkeit und Häufigkeit von Fehlern zu beurteilen.

Hinweis:
Mit den Metriken wird nicht bewertet, ob die Verarbeitungslogik der Software-Module korrekt ist oder die Syntax der Programmiersprache richtig angewendet wurde.

Software-Metriken werden unterteilt in:

• Größenmetriken (Umfangsmetriken, z.B. Lines Of Code (LOC), Halstead-Metrik)
  Mit den LOC werden die Anzahl der Kommentar-, Leer- und Befehlszeilen ermittelt.
  Mit Halstead-Metriken werden die Anzahl von Operatoren (Sprach-Elemente der Programmiersprache) und Operanden (selbst definierte Variablen usw.) ermittelt, sowie die Häufigkeit, mit diese verwendet werden. Diese Metriken sind auf beliebige Programmiersprachen anwendbar.
  
  Aus dem Verhältnis von LOC's, Operanden und Operatoren lassen sich (u.a.) folgende Werte ermitteln (schätzen):
  • wie gut ist die Software-Dokumentation?
  • wie viele logische Fehler sind zu erwarten?
  • welcher Zeitaufwand ist zur Sichtung der Source erforderlich?
  • wie verständlich ist die Source im Vergleich zu anderen Sourcen? (wie gut zu verstehen bzw. zu warten?)
• Strukturmetriken (Komplexitäts-Metriken, z.B. Mc Cabe Cyclomatic Complexity, Objektorientierte Metriken)
  Es wird gemessen, wie komplex der Programm-Ablauf ist, d.h., wie viele Verzweigungen des Programm-Ablaufs vorhanden sind.
  
  Mit den Metriken ist es möglich,
  • die Fehler-Anfälligkeit der Source zu beurteilen und
  • die Anzahl von Fehlern abzuschätzen, die beim Test des Softwaremoduls gefunden werden sollten.

Unter dem Menüpunkt Halstead-Metrik ist ein von mir erstelltes Programm beschrieben, mit welchem die Bewertung von HTML-Source-Dateien möglich ist.
Die Auswertung von Source-Modulen mit Halstead-Metriken ist nicht an eine bestimmte Programmiersprache gebunden.
Bei Bedarf kann das Programm für die Auswertung anderer Programmiersprachen umgestellt werden.