-
Die
Erfindung betrifft ein Verfahren und eine Vorrichtung zur rechnergestützten Bewertung
von Softwarequellcode und ein entsprechendes Computerprogrammprodukt.
-
Die
Erfindung beschäftigt
sich mit der Verbesserung der Codequalität von Softwaresystemen. Bei
der Verbesserung von Softwarecodequalität gibt es eine Vielzahl von
grundlegenden Schwierigkeiten. Oft gibt es keine Möglichkeiten,
Korrektheitsbeweise für
Software von nicht-trivialen großen Systemen durchzuführen. Darüber hinaus
bereitet die große Menge
an Quellcode, der während
der Lebenszeit eines Softwaresystems meist stark wächst, Schwierigkeiten
bei der Analyse des Codes. Ferner gibt es in großen Softwaresystemen eine Vielzahl
von Problemstellen, d.h. von potentiell fehlerbehafteten Stellen.
Oftmals stehen auch nicht genügend
Experten für
die Bewertung, Zuordnung und Lösung
von manuell oder automatisiert ermittelten Problemstellen im Softwarequellcode
zur Verfügung.
Ein weiteres Problem ergibt sich daraus, dass Softwarelösungen heutzutage
meistens in sehr kurzen Zeitzyklen erstellt und aktualisiert werden
müssen.
Darüber
hinaus ist bei Softwaresystemen eine Vielzahl von expliziten und
impliziten informellen Anforderungen sowie von formellen und informellen
Randbedingungen zu berücksichtigen.
Darüber
hinaus ist zu berücksichtigen,
dass es bei der Entwicklung von Software eine Vielzahl von wechselnden
technischen Realisierungsansätzen
gibt, wie z.B. Middleware, Klassenbibliotheken, unterschiedliche
Programmiersprachen und Laufzeitumgebungen. Die unterschiedlichen
Realisierungen konzentrieren sich dabei meist nur auf bestimmte
technische Aspekte, ohne andere Aspekte, wie z.B. die Sicherstellung
der Softwarequalität,
in Betracht zu ziehen.
-
Die
heutzutage mit statischen Codeanalyseverfahren ermittelten Codierungsfehlermeldungen sind
in der Regel weitgehend unstrukturiert und aufgrund der großen Menge
der Fehlermeldungen schwer zu verarbeiten. Oftmals werden deshalb
Codierungsfehler, die an sich bekannt sind, über viele Entwicklungszyklen
hinweg nicht korrigiert. Ebenso tritt oft der Fall auf, dass Codierungsfehler
falsch bzw. mit unzureichender Qualität ausgebessert werden.
-
Heutige
Lösungsansätze zur
Verbesserung der Qualität
von Softwarequellcode sind meist nicht technisch. Man verlässt sich
hierbei primär
auf die Erfahrung von Experten, welche versuchen, den Softwarequellcode
in strukturierter Weise vollständig durchzulesen.
Dabei werden von einzelnen Experten oder in einem Expertenteam potentielle
Fehlerquellen identifiziert, erörtert
und dokumentiert. Als Gesamtergebnis liegt dann meist neben einer
Liste der identifizierten Fehler und potentiellen Fehlerquellen eine
Qualitätseinschätzung in
der Form eines Prosatextes vor. In manchen Fällen wird diese Qualitätseinschätzung durch
eine Liste von Verbesserungshinweisen und Empfehlungen ergänzt.
-
Aus
dem Stand der Technik sind Ansätze
bekannt, bei denen die Fehlermeldungen von Codeanalyseverfahren
zusammengefasst werden. Diese Zusammenfassung ist meist sehr willkürlich. Beispielsweise
sind die Fehlermeldungen des C++-Analyse-Werkzeugs PC-Lint nur rudimentär nach dem möglichen
Ausmaß der
sich daraus ergebenden Probleme gegliedert. Darüber hinaus sind Ansätze bekannt,
bei denen Fehler im Softwarequellcode in technische Bereiche gegliedert
werden. Bei den bekannten Lösungsansätzen ist
es nachteilhaft, dass nach der Analyse des Softwarequellcodes einem
Benutzer keine einfache Struktur vorgegeben wird, aus der entnommen
werden kann, welche Kriterien durch die einzelnen Programmierfehler
nicht erfüllt
werden.
-
Aufgabe
der Erfindung ist es deshalb, ein Verfahren und eine Vorrichtung
zur rechnergestützten
Bewertung von Software quellcode zu schaffen, mit denen auf einfache
Weise eine strukturierte Kategorisierung der Fehler im Softwarequellcode
geschaffen wird, um anschließend
auf der Basis der Kategorisierung den Softwarequellcode schnell
verbessern zu können.
-
Diese
Aufgabe wird durch die unabhängigen Patentansprüche gelöst. Weiterbildungen
der Erfindung sind in den abhängigen
Ansprüchen
definiert.
-
Gemäß dem Verfahren
der Erfindung wird der zu bewertende Softwarequellcode zunächst unter
Berücksichtigung
von Parametern umfassend Codierungsregeln und/oder Codierungsmetriken
analysiert, wobei als Analyseergebnis im Softwarequellcode detektierte
Fehler ermittelt werden. Eine Codierungsregel ist dabei eine eindeutig
festgelegte Vorschrift, bei deren Nichterfüllen die Regel verletzt ist. Demgegenüber ist
eine Codierungsmetrik eine aus dem Softwarequellcode oder dem lauffähigen Programm
bestimmbare Größe, welche
ein Indikator für bestimmte,
in der Software enthaltene Fehler ist. Ein Beispiel einer Codierungsmetrik
ist die Anzahl der Codezeilen in einem Softwarequellcode. Codierungsmetriken
sind insbesondere abhängig
von den technischen Randbedingungen der verwendeten Computersysteme,
wie Speicherkapazitäten,
Reaktionszeiten, Durchsätzen,
Wiederanlauf-Möglichkeiten nach
einem Stoppen des Ablaufes, Möglichkeiten, Updates
einzuspielen, etc. Die detektierten Fehler werden anschließend klassifiziert,
indem sie jeweils zumindest einer Fehlerklasse aus einer Mehrzahl von
Fehlerklassen zugeordnet werden. Um eine einfache und klar strukturierte
Einteilung in Fehlerklassen zu schaffen, ist gemäß der Erfindung jeder Fehlerklasse
eine über
eine Benutzerschnittstelle ausgebbare Spezifikation zugeordnet,
welche die Fehler der jeweiligen Fehlerklasse beschreibt. Schließlich werden
diejenigen Fehlerklassen, welchen detektierte Fehler zugeordnet
sind, über
eine Benutzerstelle ausgegeben. Durch die Festlegung von Spezifikationen,
insbesondere von technischen Spezifikationen, wird bei der Kategorisierung
der Fehler klar festgelegt, welches erwünschte Entwicklungsziel nicht
erreicht wird. Dem Benutzer des Verfah rens wird somit durch die
Ausgabe der Fehlerklassen strukturiert mitgeteilt, welche spezifischen
Anforderungen der Softwarequellcode nicht erfüllt, woraufhin entsprechende Gegenmaßnahmen
ergriffen werden können.
-
Vorzugsweise
wird jeder Fehlerklasse eine der folgenden programmiertechnischen
Kategorien zugeordnet:
- – eine Kategorie betreffend
Notations-Konventionen;
- – eine
Kategorie betreffend Typen-Deklarationen und/oder Definitionen;
- – eine
Kategorie betreffend Programm-Anweisungen;
- – eine
Kategorie betreffend Speicherprobleme;
- – eine
Kategorie betreffend Software-Protokolle;
- – eine
Kategorie betreffend das Design und/oder die Architektur des Softwarequellcodes;
- – eine
Kategorie betreffend das Zeitverhalten bei der Ausführung des
Softwarequellcodes.
-
Auf
diese Weise werden die Fehler nach programmiertechnischen Kriterien
kategorisiert. Es wird hierdurch schnell und intuitiv einem Benutzer
vermittelt, in welchen programmiertechnischen Bereichen vorgegebene
Anforderungen nicht erfüllt
sind.
-
In
einer Ausführungsform
der Erfindung werden die Fehlerklassen den programmiertechnischen Kategorien über den
Detektionsmechanismus zugeordnet, mit dem Fehler einer Fehlerklasse
identifiziert werden. Auf diese Weise wird ein klares und eindeutiges
programmiertechnisches Kriterium geschaffen, über das eine Zuordnung von
Fehler zu Fehlerklassen erfolgt.
-
In
einer besonders bevorzugten Ausführungsform
der Erfindung umfasst die Spezifikation der jeweiligen Fehlerklasse
eine oder mehrere, insbesondere alle, der folgenden Beschreibungen:
- – Eine
Beschreibung eines Entwicklungsziels, welches durch die Behebung
der Fehler der entsprechenden Fehlerklasse erreicht werden soll. Mit
dem Entwicklungsziel soll klar gemacht werden, aus welchen Gründen es
sinnvoll ist, die unter dieser Fehlerklasse subsumierten Probleme zu
vermeiden.
- – Eine
Beschreibung der Verletzung des Entwicklungsziels, welche angibt,
bei welchen Fehlern in der jeweiligen Fehlerklasse das Entwicklungsziel nicht
erreicht wird. In dieser Beschreibungskategorie wird explizit auf
allgemeiner Ebene beschrieben, unter welchen Umständen das
Entwicklungsziel nicht erreicht wird.
- – Eine
Beschreibung der Ursachen für
das Verfehlen des Entwicklungsziels. Hier werden typische Ursachen
für das
Auftreten von Problemen in einer Fehlerklasse identifiziert und
diskutiert.
- – Eine
Beschreibung der möglichen
Korrekturen in Softwarequellcode, um das Entwicklungsziel zu erreichen.
Hier wird festgelegt, durch welche Maßnahmen oder Techniken das
Entwicklungsziel erreicht werden kann.
- – Eine
Beschreibung des Detektionsmechanismus, welche angibt, wie Fehler
in der jeweiligen Fehlerklasse detektiert werden. Hier wird beschrieben,
wie das durch die Fehlerklasse beschriebene Problem identifiziert
wird. Im Falle, dass die Fehlerklassen ferner noch in allgemeine und
spezifische Fehlerklassen eingeteilt sind, werden in einer allgemeinen
Fehlerklasse allgemeine Detektionstechniken aufgeführt, während bei
einer konkreten Fehlerklasse die genauen Vorschriften für das Vorliegen
der Verletzung einer Codierungsregel bzw. zur Berechnung von Werten
einer Codierungsmetrik angegeben sind.
-
Die
einzelnen Fehlerklassen können
nochmals nach ihrem Abstraktionsgrad sortiert werden. Insbesondere
können
die Fehlerklassen gemäß einer
hierarchischen Taxonomie in allgemeine, spezielle und konkrete Fehlerklassen
eingeteilt werden. Zur Verbesserung der Übersicht, Wiedererkennung und Reproduzierbarkeit
der Klassifikation können
die Taxa nach den aus dem Stand der Technik bekannten 7+ –2 Regeln
gewählt
und angeordnet werden (siehe George A. Miller: The Magical Number
Seven, Plus or Minus Two; The Psychological Review, 1956, Vol. 63,
Seiten 81 bis 97). Auf diese Weise werden verschiedene Hierarchieebenen
von Fehlerklassen geschaffen, wobei in tieferen Hierarchieebenen
die Fehlerklassen immer spezieller und konkreter werden. Die allgemeinen
Fehlerklassen fassen hierbei insbesondere die Ziele jedes Qualitätsverbesserungsprozesses
in irgendeiner Form zusammen, nämlich
die Vermeidung gerade jener Fehler, die schließlich dieser allgemeinen Fehlerklasse
zuordenbar sind. Sie geben die Richtung bzw. den Sinn und Zweck
für die
Fehlerbehebung bzw. für
die Qualitätsverbesserung
vor. Demgegenüber
fassen spezifische Fehlerklassen vorzugsweise eine Menge ähnlicher
Codierungsfehler zusammen. Sie grenzen die Gründe und die Lösungsmöglichkeiten
ein. Damit ist eine hierarchische Strukturierung der Problemklassen
möglich.
Hierdurch wird eine logische Strukturierung der konkreten Fehlerklassen
erreicht und darüber
hinaus die Möglichkeit
geschaffen, für
einzelne Fehlerklassen eine Lösungsrichtung
für die
Behebung der damit assoziierten Probleme vorzugeben. Konkrete Fehlerklassen
sind demgegenüber
vorzugsweise direkt zugeordneten Codierungsregeln und Metriken zugewiesen,
welche lokalisierte Fehler bzw. Grenzwertüberschreitungen von Metriken
beschreiben. Den Fehlern in den konkreten Fehlerklassen sind insbesondere
automatisierbare Lösungen für die Behebung
der Probleme zugeordnet.
-
Die
hierarchische Strukturierung der Fehlerklassen kann dazu verwendet
werden, um ausgehend von einem identifizierten Problem, d.h. einer
allgemeinen Fehlerklasse, auf systematische Weise zu überprüfen, wodurch
das Problem verursacht wird. Diese Prüfung könnte dann systematisch durch
Prüfung
der entsprechenden spezifischen und konkreten Fehlerklassen erfolgen.
-
In
einer weiteren Ausführungsform
der Erfindung besteht ferner die Möglichkeit, detektierte Fehler
nach vorgegebenen Kriterien zu filtern, so dass die angezeigten
Fehlerklassen auf bestimmte interessierende Fehler eingeschränkt werden.
-
In
einer besonders bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens
wird eine Bewertung der detektierten Feh ler durchgeführt, wobei
für jede
ausgegebene Fehlerklasse eine Qualitätsbewertung der Fehlerklasse
auf der Basis der darin enthaltenen Fehler über eine Benutzerschnittstelle
ausgegeben wird. Somit bekommt der Benutzer sofort eine Rückmeldung
dahingehend, wie schwer die im Softwarequellcode in den einzelnen
Fehlerklassen enthaltenen Fehler sind. Vorzugsweise wird in dem
erfindungsgemäßen Verfahren
ferner eine Gesamtbewertung der Qualität des Softwarequellcodes auf
der Basis der Qualitätsbewertungen
der Fehlerklassen ermittelt und über
eine Benutzerschnittstelle ausgegeben. Auf diese Weise erhält ein Benutzer
sofort einen Überblick,
wie die Gesamtqualität
des Softwarequellcodes einzustufen ist. Die Qualitätsbewertungen
der Fehlerklassen und/oder die Gesamtqualitätsbewertung beruht hierbei
vorzugsweise auf vorgegebenen Maßzahlen. Mit solchen Maßzahlen
kann insbesondere auf einfache Weise die Gesamtqualitätsbewertung
dadurch ermittelt werden, dass die Maßzahlen der Qualitätsbewertungen
der Fehlerklassen aufsummiert werden.
-
In
einer besonders bevorzugten Ausführungsform
der Erfindung ist das Verfahren derart ausgestaltet, dass über eine
Benutzerschnittstelle eine Soll-Qualität des Softwarequellcodes eingebbar
ist, wobei die Soll-Qualität
mit der Ist-Qualität
gemäß den Qualitätsbewertungen
der Fehlerklassen und/oder der Gesamtqualitätsbewertung verglichen wird
und das entsprechende Vergleichsergebnis über eine Benutzerschnittstelle
ausgegeben wird. Hierdurch können
selbsttätig
durch einen Benutzer bestimmte erwünschte Qualitätsanforderungen
vorgegeben werden, wobei das Verfahren automatisiert diese Qualitätsanforderungen
berücksichtigt
und ausgibt, ob diese Qualitätsanforderungen
durch den Softwarequellcode tatsächlich
erfüllt
werden.
-
Vorzugsweise
werden die Qualitätsbewertungen
der Fehlerklassen und/oder der Gesamtqualitätsbewertung in einem abrufbaren
Speicher hinterlegt, wodurch eine Qualitätshistorie von verschiedenen
Versionen von Softwarequellcodes im Speicher gespeichert wird. Auf
diese Weise bekommt ein Benutzer sehr leicht einen Überblick
darüber,
wie sich die Qualität über die
verschiedenen Softwareversionen hinweg verändert hat und ob die durchgeführten Qualitätsmaßnahmen
in der Vergangenheit auch tatsächlich
zu einer signifikanten Qualitätsverbesserung
der Software geführt
haben. Vorzugsweise sind in der generierten Qualitätshistorie
auch die jeweiligen Ist-Qualitäten
und Soll-Qualitäten
der Versionen des Softwarequellcodes hinterlegt.
-
In
einer weiteren, besonders bevorzugten, Ausführungsform der Erfindung werden
aus den Qualitätsbewertungen
der Fehlerklassen Änderungsanforderungen
an den Softwarequellcode generiert, und aus den Änderungsanforderungen werden Änderungsmitteilungen
erstellt, wobei die Änderungen in
einer Änderungsmitteilung
jeweils einer Person oder einem Personenkreis zugeordnet sind, der
für die
Durchführung
der Änderungen
in der Änderungsmitteilung
verantwortlich ist. Auf diese Weise wird automatisiert eine Zuweisung
der im Softwarequellcode durchzuführenden Änderungen an den dafür Verantwortlichen
generiert. Vorzugsweise können
darüber hinaus
Kriterien über
eine Benutzerschnittstelle eingegeben werden, wobei diese Kriterien
bei der Generierung der Änderungsanforderungen
zu berücksichtigen
sind. Solche Kriterien sind beispielsweise angepasste Qualitätsbewertungen,
d.h. es wurde manuell durch Experten ermittelt, dass die Qualität aufgrund äußerer Umstände etwas
anders zu bewerten ist, als dies automatisiert im erfindungsgemäßen Verfahren erfolgt
ist. Darüber
hinaus können
beispielsweise Prioritäten
betreffend die Behebung der Fehler vorgegeben werden, d.h. es kann
festgelegt werden, welche Fehler bevorzugt zu beheben sind. Solche
Informationen können
dann in die automatisch generierten Änderungsmitteilungen einfließen. In
einer besonders bevorzugten Ausführungsform
werden die Änderungsmitteilungen
jeweils automatisiert der Person oder den Personenkreis übermittelt,
der für
die Durchführung
der Änderungen
in der Änderungsmitteilung
verantwortlich ist. Beispielsweise kann der verantwortlichen Person
die Änderungsmitteilung
automatisiert über
eine E-Mail als Datei übermittelt
werden.
-
In
einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens können die Änderungsmitteilungen
ferner Hinweise zur Durchführung
der Änderung
und/oder eine Abschätzung
des Aufwands der Änderungen
enthalten. Es kann hierbei eine beliebige Metrik zur Bestimmung
des Aufwands verwendet werden, beispielsweise eine Kostenmetrik, welche
als Ergebnis die Mannstunden angibt, welche gebraucht werden, um
die Änderung
durchzuführen.
-
In
einer bevorzugten Ausführungsform
der Erfindung enthalten die Hinweise zur Durchführung der Änderungen auch Musterlösung zur Änderung des
Softwarequellcodes, wobei den Musterlösungen vorzugsweise jeweils
ein Aufwand zur Durchführung der
Musterlösung
zugeordnet ist.
-
In
einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens umfassen die
Fehlerklassen Qualitätsfehlerklassen,
welche die Fehler nach Qualitätskriterien
kategorisieren. Insbesondere können
die Codierungsfehler einem Qualitätsmodel zugeordnet werden,
wodurch eine von einer rein technischen Klassifikation unabhängige Sichtweise
auf die Codierungsfehler geschaffen wird.
-
Neben
dem oben beschriebenen Verfahren betrifft die Erfindung ferner eine
Vorrichtung zur rechnergestützten
Bewertung von Softwarequellcode, umfassend:
- – ein Analysemittel
zum Analysieren des Softwarequellcodes unter Berücksichtigung von Parametern
umfassend Codierungsregeln und/oder Codierungsmetriken, wobei durch
das Analysemittel als Analyseergebnis im Softwarequellcode detektierte
Fehler ermittelt werden;
- – ein
Klassifizierungsmittel zum Klassifizieren der detektierten Fehler,
indem die detektierten Fehler jeweils zumindest einer Klasse aus
einer Mehrzahl von Fehlerklassen zugeordnet werden, wobei jeder
Fehlerklasse eine über
eine Benutzerschnittstelle ausgebbare Spezifikation zuge ordnet ist,
welche die Fehler der jeweiligen Fehlerklasse beschreibt;
- – ein
Ausgabemittel zum Ausgeben derjenigen Fehlerklassen, welchen detektierte
Fehler zugeordnet sind, über
eine Benutzerschnittstelle.
-
Die
Erfindung betrifft darüber
hinaus ein Computerprogrammprodukt mit einem auf einem maschinenlesbaren
Träger
gespeicherten Programmcode zur Ausführung des oben beschriebenen
erfindungsgemäßen Verfahrens,
wenn das Programm auf einem Rechner läuft.
-
Ausführungsbeispiele
der Erfindung werden nachfolgend anhand der beigefügten Figuren
detailliert beschrieben.
-
Es
zeigen:
-
1 eine
schematische Darstellung eines Softwareentwicklungsprozesses, in
dem das erfindungsgemäße Verfahren
eingesetzt wird;
-
2 eine
Ausführungsform
einer erfindungsgemäßen Vorrichtung
zur rechnergestützten Bewertung
von Softwarequellcode.
-
Im
Folgenden wird eine Ausführungsform des
erfindungsgemäßen Verfahrens
beschrieben, welches die folgenden, bereits oben erwähnten Fehlerklassen
enthält:
Notations-Konventionen;
Typen-Deklarationen und/oder Definitionen; Programm-Anweisungen; Speicherprobleme;
Software-Protokolle;
Design und/oder Architektur; Korrektheit; Zeitverhalten.
-
Jeder
dieser Fehlerklassen ist eine Spezifikation in der Form einer Beschreibung
zugeordnet, welche die bereits im vorangegangen erwähnten folgende
Kategorien umfasst Entwicklungsziel; Verletzung; Ursachen für das Verfehlen
des Entwicklungsziels; Korrekturen; Detektionsmechanismus; Auswirkungen
des Verfehlens des Entwicklungsziels.
-
Im
Folgenden wird für
jede der oben genannten Fehlerklassen die entsprechende Beschreibung gemäß der soeben
genannten Beschreibungskategorien gegeben.
-
1. Notationskonventionen
-
A. Entwicklungsziel
-
Die
Quellen von Softwareprogrammen sollten so lesbar wie möglich sein,
um verständlich
und wartbar zu sein. Die Notation der Quellen als Text spielt hier
eine wesentliche Rolle. Die Notationen betreffen hierbei insbesondere
Namen für
Symbole und Artefakte, den Stil und die Dokumentation.
-
Namen:
-
Die
erforderlichen, in den Anforderungen implizit oder explizit genannten
physischen oder virtuellen Phänomene
eines Anwendungsbereichs werden systematisch, eindeutig und sowohl
für den
Fachexperten als auch den Softwareingenieur verständlich bezeichnet.
-
Stil:
-
Jede
Programmiersprache definiert durch ihre Syntax die Grammatik, d.h.,
welche Inhalte durch die Programmiersprache auf welche Weise auszudrücken sind.
Die Syntax legt nicht fest, in welcher Form (Einrückungen,
Klammerungen, Zeilenumbrüche,
Formate von Kommentaren etc.) Programme geschrieben werden müssen. Daneben
gibt es noch stilistische Regeln und Nuancen, in welchem Kontext welche
Sprachkonstrukte wie einzusetzen sind, und zwar unabhängig davon,
ob auch alternative Formulierungen aufgrund der Syntax der Programmiersprache
möglich
sind. Entwicklungsziel im Hinblick auf den Stil ist es, die Programmiersprache
aus stilistischer Sicht so zu verwenden, dass die in der Branche etablierten
und als qualitativ gut empfundenen stilistischen Regeln eingehalten
werden.
-
Dokumentation:
-
Die
Dokumentation liefert über
den Programmcode hinausgehende, wesentliche Hinweise zum Verständnis des
Softwarequellcodes. Der Softwareentwickler beschreibt hierbei seine über das
Design hinausgehenden Entscheidungen.
-
B. Verletzung
-
Namen:
-
Namen
oder Bezeichner im Programmcode sind entweder mehrdeutig oder lassen
keinen Schluss auf das zugrunde liegende Phänomen der Anwendungsdomäne zu. Darüber hinaus
lässt es sich
oft beobachten, dass einzelne Entwickler oder Entwicklergruppen
ein lokales Vokabular aufbauen, das von Außenstehenden nicht verstanden
werden kann.
-
Stil:
-
Sowohl
eine schlechte Namenswahl als auch ein schlechter Programmierstil
führt zu
einer Personalisierung der Softwareentwicklung, d.h., der entsprechende
Programmtext kann nur noch vom ursprünglichen Entwickler des Programms
mit vertretbarem ökonomischen
Aufwand gewartet und weiterentwickelt werden.
-
C. Ursachen für das Verfehlen
des Entwicklungsziels
-
Fehlende
oder sprachlich uneinheitliche Anforderungsspezifikationen definieren
keinen klaren Wortschatz, der für
die Namensgebung herangezogen werden könnte. Daher verwenden die Entwickler frei
erfundene Bezeichner, die weder definiert sind noch eindeutig sind.
-
In älteren Programmiersprachen
waren die Länge
und der Aufbau von Bezeichnern aus Gründen der Ressourcenknappheit
oder aufgrund mangelhafter Compilertechnologie eingeschränkt. Heute
findet man immer noch Nachwirkungen dieser Beschränkungen auch
bei der Verwendung moderner Programmiersprachen, obwohl keine technische
Notwendigkeit mehr dafür
besteht.
-
Codierrichtlinien
und die bestmögliche
Umsetzung dieser Richtlinien sind nicht bekannt oder werden von
dem Softwareentwickler nicht akzeptiert.
-
Weitere
Gründe
für das
Verfehlen des Entwicklungsziels ist fehlendes Problembewusstsein und/oder
fehlendes Gesamtverständnis.
-
D. Korrektur
-
- – Vorgabe
von allgemeinen Namenskonventionen und von projektspezifischen Namenskonventionen.
Die projektspezifischen Namenskonventionen regeln den Umgang mit
den Begriffen der Domäne,
indem beispielsweise ein Glossar wichtiger Begriffe im Kontext des
Softwareprojektes vorgegeben wird.
- – Vorgabe
von Programmierrichtlinien, in denen Fragen der Formatierung (Einrückungen,
Klammersetzung etc.) definiert sind. Darüber hinaus wird in den Programmierricht
linien beschrieben, welche Sprachkonstrukte in welchem Kontext wie zu
verstehen sind.
- – Schulung
der Mitarbeiter
- – Durchführung von
Codeüberprüfungen mit
dem Schwerpunkt auf Namenswahl im Programmierstil.
- – Sog.
Reengineering betroffener Codeteile auf der Basis der Namenskonventionen
und der Programmierrichtlinien.
-
E. Detektionsmechanismus
-
Die
Einhaltung von Programmierrichtlinien, d.h. die Einhaltung stilistischer
Vorgaben, kann in der Regel automatisiert durch statische Codeanalyse-Werkzeuge
sichergestellt werden. Die Einhaltung von Namenskonventionen kann – für allgemeine
Namenskonventionen – ebenfalls
durch entsprechende statische Codeanalyse-Werkzeuge erfolgen. Die
semantisch richtige Ver wendung von Namen im Kontext der betrachteten
Domäne
kann nur manuell durch entsprechende Reviews sichergestellt werden.
-
F. Auswirkungen
-
Der
Quellcode wirkt unordentlich und handwerklich schlecht. Uneindeutige
Bezeichner verursachen Kommunikationsprobleme. Dies hat direkte Auswirkungen
auf die Wartbarkeit des Codes.
-
2. Typen-Deklarationen
und Definitionen
-
A. Entwicklungsziel
-
In
einer statisch typisierten Programmiersprache sind alle Bezeichner
mit demjenigen Typennamen assoziiert, der am besten zum Verwendungskontext
des Bezeichners passt. In diesem Sinne ist der Typname dann gut
gewählt,
wenn keine Verwendungsfehler des Bezeichners vorkommen können bzw.
auch keine expliziten Typumwandlungen erforderlich sind.
-
Der
Gültigkeitsbereich
von Bezeichnern ist so zu wählen,
dass nur jene Typen nach außen
sichtbar werden, die auch tatsächlich
benötigt
werden.
-
B. Verletzung
-
Eine
Verletzung des Entwicklungsziels liegt dann vor, wenn Typen verwendet
werden, die im Kontext der Verwendung von Bezeichnern nicht sinnvoll
sind. Eine Verletzung des Entwicklungsziels liegt ferner dann vor,
wenn die Deklaration eines Bezeichners so erfolgt, dass dem Verwender
eines Bezeichners (z.B. der Parameter einer Methode) aufgrund des
verwendeten Typs Implementierungsdetails bekannt werden, die aus
sachlicher Sicht nicht bekannt sein müssten.
-
C. Ursachen für das Verfehlen
des Entwicklungsziels
-
- – In
den Programmierrichtlinien werden zu diesem Thema keine Aussagen
gemacht.
- – Mangelhaftes
Verständnis
der Entwickler für
allgemeine softwaretechnische Designaspekte, wie Gestaltung von
Schnittstellen, Kopplung und Kohäsion
von Typen etc.
- – Mangelhaftes
Verständnis
der Typkonzepte einer Programmiersprache, z.B. Schnittstellenvererbung,
Implementierungsvererbung, abstrakte Klassen usw.
- – Unzureichende
Refactoring nach Design-Änderungen,
d.h. es werden die aufgrund eines Refactoring neu geschaffenen allgemeineren
Typen nicht konsistent im gesamten Quelltext nachgezogen, d.h. anstelle
der alten Typen verwendet.
- – Anforderungen
sind z.B. bei Schnittstellendefinition nicht definiert oder bekannt.
Daher werden hier Typen festgelegt, die später bei der Implementierung
korrigiert werden müssen.
-
D. Korrektur
-
- – Schulung
der Entwickler mit Fokus auf softwaretechnische Grundlagen des Designs
und hinsichtlich der Typkonzepte der jeweiligen Programmiersprache.
- – Verbesserung
der Programmierrichtlinien.
- – Systematische
Durchführung
von Code-Reviews.
-
Es
kann sinnvoll sein, Verletzungen im vernünftigen Rahmen oder bei bestimmten
Designkonzepten zuzulassen.
-
E. Detektionsmechanismus
-
Fehler
hinsichtlich von Typen-Deklarationen und Definitionen werden aus
dem Regelsatz der Codeanalysatoren oder aus daraus abgeleiteten
Steuerungsmetriken ermittelt, z.B. aus der Anzahl an Typkonversionen,
der Anzahl an Typverletzungen usw.
-
F. Auswirkungen
-
Durch
die Verwendung von Typkonvertierungs-Operatoren kann es – je nach
der Typkonvertierung – zu
einem Verlust von Rechengenauigkeit bis hin zum Programmabsturz
kommen.
-
Bei
Missachtung der in der Softwaretechnik üblichen Sichtbarkeitsregeln
für Typen
kommt es zu unnötigen
Kopplungen zwischen einzelnen Softwareartefakten, welche die Änderbarkeit
des Softwarequellcodes negativ beeinflussen.
-
3. Programm-Anweisungen
-
A. Entwicklungsziel
-
Grundsätzliches
Entwicklungsziel ist es, die Strukturierung des Quellcodes im Kleinen
so vorzunehmen, dass damit die üblichen
softwaretechnischen Qualitätskriterien
erfüllbar
sind. Die Strukturierung im Kleinen beschäftigt sich mit folgenden Aspekten:
- – Komplexität von Ausdrücken, insbesondere
von logischen und arithmetischen Ausdrücken.
- – Adäquate Verwendung
unterschiedlicher Schleifenkonstrukte.
- – Adäquate Verwendung
unterschiedlicher Selektionsanweisungen.
- – Komplexität von Funktionen
und Methoden.
-
Es
soll eine, zumindest näherungsweise,
minimale und nachvollziehbare Sequenz von Anweisungen zur Realisierung
der geforderten funktionalen und nicht-funktionalen Merkmale verwendet
werden. Dabei ist der konzeptionelle Ablauf in geeigneter Form abzubilden.
-
B. Verletzung
-
Die
Codierungsfehler dieser Fehlerklasse sind abhängig von der Art der Anweisung.
Entweder enthält
die Anweisung semantisch falsche Bestandteile oder die Anweisung
ist zumindest semantisch fragwürdig, überflüssig, zu
komplex oder unvollständig.
-
C. Ursachen für das Verfehlen
des Entwicklungsziels
-
Es
liegen Zeit- und/oder Ausbildungsmängel bei den Softwareentwicklern
vor.
-
B. Korrektur
-
Es
muss zuerst die vom Softwareentwickler verwendete Anweisung zunächst beschrieben
und dann codiert werden. Eine Methode zur Vermeidung von Anweisungsfehlern
ist sog. „literate
programming". Die
Korrektur kann durch den Entwickler eventuell nach einer Schulung
vorgenommen werden.
-
E. Detektionsmechanismus
-
Anweisungsfehler
werden aus dem Regelsatz der Codeanalysatoren und daraus abgeleiteter Steuerungsmetriken
detektiert, z.B. aus der Anzahl zweifelhafter, redundanter und unerreichbarer
Aussagen.
-
F. Auswirkungen
-
Eine
Verletzung des oder der Entwicklungsziele kann – je nach Art der Verletzung – eine negative
Auswirkung auf die Korrektheit des Programms haben.
-
Gibt
es keine Auswirkungen auf die Korrektheit, entsteht durch die Verletzung
des Entwicklungsziels schwer wartbarer Softwarecode, der wiederum in
erster Linie nur von den ur sprünglichen
Entwicklern mit ökonomisch
vertretbarem Aufwand gewartet und weiterentwickelt werden kann.
-
4. Speicherprobleme
-
A. Entwicklungsziel
-
Entwicklungsziel
ist es, mit dem Hauptspeicher sparsam umzugehen, d.h. nur notwendigen Speicher
zum geeigneten Zeitpunkt zu allokieren und ggf. rechtzeitig freizugeben.
Darüber
hinaus muss sichergestellt werden, dass sich der Hauptspeicherplatz
zu jedem Zeitpunkt in einem konsistenten Zustand befindet. Weiterhin
muss sichergestellt sein, dass Variablen, die explizit Speicher
referenzieren, zu jedem Zeitpunkt in einem konsistenten Zustand sind,
d.h. keine ungewollten Null-Werte aufweisen, keine falschen Speicheradressen
enthalten, usw.
-
B. Verletzung
-
- – Eine
Verletzung des Entwicklungsziels liegt dann vor, wenn in unnötiger Weise
Speicher allokiert wird und vergessen wird, Speicher rechtzeitig
wieder freizugeben.
- – Das
Entwicklungsziel kann ferner durch unsachgemäße Verwendung von Sprachkonstrukten
verletzt werden, wobei solche Sprachkonstrukte zu fehlerhaften Manipulationen
von Speicherinhalten oder Speicheradressen führen. Operatoren, welche typischerweise
unsachgemäß verwendet werden,
sind arithmetische Adressoperationen und Typkonvertierungs-Operatoren.
-
C. Ursachen für das Verfehlen
des Entwicklungsziels
-
Ursachen
sind insbesondere Zeit- und Ausbildungsmängel bei den Softwareentwicklern,
sowie fehlende Designkonzepte.
-
D. Korrektur
-
Die
Korrektur von Speicherproblemen kann durch den Entwickler selbst,
eventuell nach einer Schulung, vorgenommen werden.
-
E. Detektionsmechanismus
-
Speicherprobleme
können
aus dem Regelsatz der Codeanalysatoren und daraus abgeleiteter Steuerungsmetriken
ermittelt werden, z.B. aus der Anzahl zweifelhafter oder falscher
Aussagen, die den Zustand des Speichers ändern.
-
F. Auswirkungen
-
Fehler
bei der Verwaltung des Speichers führen zu inkonsistenten Zuständen oder
zu hohem Speicherverbrauch und stellen oft indirekt die Realisierung
der geforderten funktionalen und nicht-funktionalen Eigenschaften
des Programms in Frage, insbesondere die Laufzeitstabilität.
-
5. Software-Protokolle
-
A. Entwicklungsziel
-
Software-Protokolle
beschreiben, in welcher Reihenfolge programmtechnisch bestimmte
Vorgänge
ausgeführt
werden sollen. Ein Beispiel eines Software-Protokolls ist z.B. die
Veröffentlichung
eines Schnittstellen-Protokolls. Entwicklungsziel ist es hierbei,
dass die Software-Protokolle bei der Programmierung derart berücksichtigt
werden, dass das Programm dem Systemzustand konsistent hält. Dafür werden
Aufrufreihenfolgen von Prozeduren definiert und diese an bestimmte
Zustände
und Eingaben geknüpft.
Dies ist z.B. bei asynchronen Systemen, in Fehlersituationen, bei
der Verwendung von Nebenläufigkeit
unter Benutzung von mehrfach gleichzeitig verwendeten externen Ressourcen
besonders wichtig.
-
B. Verletzung
-
Das
Entwicklungsziel ist verletzt, wenn Prozeduren in einer Reihenfolge
oder unter den falschen Bedingungen aufgerufen werden, so dass ein
inkonsistenter Systemzustand entsteht.
-
C. Ursachen für das Verfehlen
des Entwicklungsziels
-
Die
implizit oder explizit vorgegebenen Protokolle werden nicht beachtet.
Implizite Protokolle sind nicht ausreichend bekannt bzw. dokumentiert.
-
D. Korrektur
-
Implizite
Protokolle sollten verständlich
dokumentiert werden. Die Entwickler sollten bezüglich der verwendeten Protokolle
geschult werden.
-
E. Detektionsmechanismus
-
Eine
Detektion der Verletzung von Software-Protokollen kann durch manuelle
Reviews, der Analyse von Aufrufbäumen
mit Datenflussanalyse oder der verwendeten Automaten erfolgen. Die
Protokolle können
auch automatisiert durch statische und dynamische Codeanalyse-Werkzeuge überprüft werden.
-
F. Auswirkungen
-
Es
entsteht ein Softwaresystem in einem inkonsistenten bzw. instabilen
Zustand.
-
6. Design
und Architektur
-
A. Entwicklungsziel
-
Primäres Entwicklungsziel
ist es, die Architektur und das Design eines Systems so zu gestalten, dass
damit die an dieses System gestellten funktionalen und nicht-funktionalen
Anfor derungen erfüllt werden
und auch erwartete Änderungen
und Erweiterungen der Anforderungen im Design bzw. in der Architektur
antizipiert sind. Neben den produkt- und projektspezifischen Anforderungen
müssen
die Architektur und das Design allgemeine softwaretechnische Qualitätsanforderungen
erfüllen.
Diese Anforderungen sind insbesondere:
- – Sicherstellung
hoher, insbesondere funktionaler Kohäsion innerhalb eines Moduls
oder eines Subsystems.
- – Sicherstellung
geringer Kopplung zwischen Modulen innerhalb eines Subsystems bzw.
zwischen Subsystemen.
- – Angemessene
Komplexität
im Sinne der von einem Modul oder einem Subsystem zur Verfügung gestellten
Methoden bzw. Typen.
-
B. Verletzung
-
Verletzungen
des Entwicklungsziels liegen dann vor, wenn die definierten funktionalen
und nicht-funktionalen Anforderungen aufgrund eines schlecht gewählten Designs
oder einer schlecht gewählten
Architektur nicht erfüllt
werden können.
Eine Verletzung liegt auch dann vor, wenn zwar die projekt- oder
produktspezifischen Anforderungen erfüllt sind, aber Kopplung, Kohäsion und
Komplexität
nicht angemessen sind.
-
C. Ursachen für das Verfehlen
des Entwicklungsziels
-
Ursachen
sind insbesondere eine fehlende Architektur für das zu entwickelnde Softwaresystem.
-
Weitere
Ursachen sind fehlende Zeit und Steuerung der Umsetzung der Architektur
bzw. Mangel an Ressourcen für
die systematische Restrukturierung von Softwaresystemen.
-
Weitere
Ursachen sind unnötige
Beziehungen innerhalb des Softwaresystems sowie die Zerteilung des
Systems nicht nach architektonischen Kriterien, wie z.B. Kopplung
und Kohäsion,
sondern nach Standort oder Bearbeiter.
-
Eine
weitere Ursache ist, dass das Softwaresystem wegen Zeitmangel nicht
ausreichend gepflegt wurde.
-
D. Korrektur
-
Es
muss bei der Entwicklung des Softwarequellcodes ein Architekt oder
Projektleiter (falls kein Architekt vorhanden) eingesetzt werden.
-
D. Detektionsmechanismus
-
Die
Ermittlung von Fehlern in Design oder Architektur kann manuell oder
durch ein Analysetool (z.B. Sotograph) erfolgen.
-
F. Auswirkungen
-
Entwicklungs-
und Wartungskosten steigen. Im Extremfall kann das System nicht
mehr gewartet werden und muss neu geschrieben werden.
-
7. Korrektheit
-
A. Entwicklungsziel
-
Unter
Korrektheit wird hier nicht das explizite Übereinstimmen einer Lösung mit
spezifizierten Anforderungen verstanden. Vielmehr geht es aus Sicht der
internen Codequalität
darum, jene Codestellen zu identifizieren, die unabhängig von
der konkreten Anforderung inkorrekt sein müssen.
-
B. Verletzung
-
Eine
Verletzung liegt dann vor, wenn der Quelltext offensichtliche Fehler
enthält,
die unabhängig
von den konkreten Anforderungen sind. Beispiele dafür sind Verzweigungen
in Switch-Anweisungen, die nie erreicht werden können, oder unbenutzte lokale
Variablen.
-
C. Ursachen für das Verfehlen
des Entwicklungsziels
-
Hier
liegen meist Verständnismängel beim Programmierer
oder logische Codierungsfehler vor.
-
D. Korrektur
-
Eine
Korrektur von Verständnisfehlern
kann durch entsprechende Schulung der Entwickler erfolgen. Codierungsfehler
können
durch den Entwickler selbst korrigiert werden.
-
E. Detektionsmechanismus
-
Es
besteht die Möglichkeit,
Korrektheitsfehler statisch zu detektieren, wenn eine formale Beschreibung
des geforderten Ergebnisses zusammen mit der imperativen Realisierung
vorliegt. Hier kann dann, meist nur in Teilbereichen, eine Diskrepanz festgestellt
werden. Zusätzlich
können
hier Code-Reviews
und Inspektionen zum Auffinden dieser Fehler durchgeführt werden.
-
F. Auswirkungen
-
Korrektheitsfehler
stellen die Realisierung der impliziten Anforderungen des Softwaresystems in
Frage.
-
8. Zeitverhalten
-
A. Entwicklungsziel
-
Softwaresysteme
müssen
mit der ihnen zur Verfügung
stehenden Rechenzeit sorgfältig
umgehen, und zwar unabhängig
davon, welches konkrete Zeitverhalten durch die Spezifikation gefordert
wird. Darüber
hinaus muss jedes Softwaresystem die richtigen Konstrukte für die Synchronisation
paralleler Ausführungskontexte
korrekt verwenden. Dies betrifft sowohl die Synchronisation in verteilten
Systemen als auch die Synchronisation innerhalb eines Betriebssystem-Prozesses.
Zeitabhän gige
Systeme und Systeme mit Schnittstellen zu zeitabhängigen Systemen
unterliegen hier besonderen Anforderungen.
-
B. Verletzung
-
Eine
Verletzung des Entwicklungsziels tritt dann auf, wenn das System
unzulängliche
Synchronisierungsmechanismen aufweist. Die beobachtbaren Folgen
sind Blockaden, Reihenfolgeprobleme, sinnlose Operationen, ineffiziente
Algorithmen, unzulängliche
Antwortzeiten und mangelnder Durchsatz.
-
C. Ursachen für das Verfehlen
des Entwicklungsziels
-
Das
Softwaresystem wurde nur für
einen Verarbeitungskontext entworfen, entwickelt und getestet. Bei
den Entwicklern des Systems liegen keine Erfahrungen mit nebenläufigen Systemen
vor, d.h. mit Systemen mit mehreren gleichzeitig abgearbeiteten
Verarbeitungskontexten.
-
D. Korrektur
-
Eine
Korrektur kann durch Schulung der Mitarbeiter, durch ReDesign des
Softwarecodes oder durch Codekorrektur erfolgen.
-
E. Detektionsmechanismus
-
Fehler
im Zeitverhalten können
durch Datenflussanalyse über
Aufrufgraphen oder durch Überprüfung von
Codierungsregeln detektiert werden.
-
F. Auswirkungen
-
Systeme
mit Mängeln
im Zeitverhalten sind instabil, unzuverlässig und haben Schwierigkeiten, die
geforderten Antwortzeiten bzw. den geforderten Durchsatz zu gewährleisten.
-
Neben
den oben beschriebenen acht Fehlerklassen können ggf. noch weitere Fehlerklassen
auftreten, welche beispielsweise in einer Kategorie „Sonstiges" zusammengefasst
sind. Dort sind technologie-, domänen- oder projektspezifische
Fehlerklassen gesammelt.
-
1 zeigt
ein Flussdiagramm eines Softwareentwicklungsprozesses, in dem eine
Ausführungsform
des erfindungsgemäßen Verfahrens
eingebettet ist. Als Ausgangspunkt des Verfahrens liegt das Softwaresystem
in der Form eines Softwarequellcodes SQ vor. Zunächst wird gemäß dem erfindungsgemäßen Verfahren
der Softwarequellcode anhand von Codierungsregeln bzw. Metriken
analysiert, was durch Schritt 1 angedeutet ist. Als Ergebnis
werden entsprechende Codierungsfehler ER klassifiziert, d.h. in
entsprechende Fehlerklassen EC eingeteilt. Zur Analyse des Softwarecodes
können
bekannte statische Codeanalyse-Werkzeuge oder andere Methoden verwendet
werden, wie z.B. Standard-Prüfprozeduren.
Die Prüfprozeduren
und deren Parameter können
beispielsweise aus der letzten Iteration des Projektes, d.h. der
letzten Softwareversion, stammen. Hierbei sind insbesondere die
Codierungsregeln bzw. Metriken entsprechend vorgegebener Anforderungen
angepasst.
-
Nach
der Erzeugung der entsprechenden Fehlerklassen wird in einem Schritt 2 eine
Gesamtbeurteilung der Qualität
des gewählten
Parametersatzes der Prüfprozeduren
durch Experten durchgeführt.
Es erfolgt eine Auswahl der Grenzwerte in Abhängigkeit von Domänen, Architektur
und Softwaretechnologie. Im Schritt 201 wird dann überprüft, ob die
Fehlerklassen, welche mit dem erfindungsgemäßen Verfahren automatisiert
ermittelt wurden, sich mit der in Schritt 2 vorgenommenen
Gesamtbeurteilung durch Experten decken. Sollte dies nicht der Fall sein
(N = Nein), erfolgt im Schritt 3 eine Erweiterung und Anpassung
der Codierungsregeln und Codierungsmetriken. Dabei fließen manuelle
Regeln MR und Erfahrung E ein. Ein derart angepasster Regelsatz
R fließt
dann in das erfindungsgemäße Verfahren
ein, wobei mit dem angepassten Regelsatz dann wieder im Schritt 1 die
entsprechenden Fehler ER und Fehlerklassen EC ermittelt werden.
Die Schritte 1, 2, 201 und 3 werden
so lange iteriert, bis im Schritt 201 festgestellt wird,
dass das Ergebnis der Experten sich mit dem automatisiert ermittelten
Ergebnis des erfindungsgemäßen Verfahren
deckt. In diesem Fall (Y = Ja) wird zu Schritt 4 übergegangen.
-
Im
Schritt 4 erfolgt eine Vereinbarung oder Anpassung von
Qualitätszielen
mit den Verantwortlichen (Teilprojektleiter oder deren Qualitätssicherungs-Verantwortlichen).
Hierbei werden insbesondere zu erreichende Qualitätsziele
vereinbart bzw. bereits festgelegte Qualitätsziele angepasst.
-
Im
Schritt 5 wird die Ist-Qualität des Softwarequellcodes mit
der Soll-Qualität
verglichen. Gemäß Schritt 6 wird
dann ein Analyseergebnis ausgegeben, welches für die vorliegende Softwarequellcodeversion
den Vergleich von Soll-Qualität
und Ist-Qualität enthält. Diese
Analyse wird im Schritt 7 in einem Speicher gespeichert,
in dem die Qualitätshistorie
von vorhergehenden Softwarequellcodeversionen hinterlegt ist.
-
Im
Schritt 8 erfolgt schließlich eine manuelle Prüfung der
Analyseergebnisse, wobei eventuell Änderungen im Hinblick auf die
im nächsten
Schritt generierten Änderungsanforderungen
durchgeführt werden.
Man nennt diese Analyse auch „Code
Quality Control".
Hierbei wird der Code nochmals überprüft und es
werden eventuell Anpassungen der Qualitätsbewertungen vorgenommen bzw.
Prioritäten
im Hinblick auf durchzuführende Änderungen
festgelegt.
-
Im
Schritt 9 erfolgt schließlich die automatische Generierung
der Änderungsanforderungen
sowie die automatische Erstellung von Änderungsmitteilungen an die
entsprechenden Verantwortlichen, eventuell mit einem Lösungshinweis
und einer Kostenschätzung.
Lösungshinweise,
insbesondere Musterlösungen,
werden dabei aus einer Lösungsdatenbank
LB entnommen.
-
Schließlich werden
im Schritt 10 die gemäß den Änderungsmitteilungen
an die Verantwortlichen übermittelten Änderungen
in dem Softwarequellcode eingebaut und schließlich im Schritt 11 integriert.
Als Ergebnis erhält
man im Schritt 12 schließlich eine neue Version des
Softwaresystems mit neuem Softwarequellcode SQ. Der neue Quellcode
fließt
dann wieder in Schritt 1 des Verfahrens zur erneuten Überprüfung der
neuen Version ein.
-
Die
vorangegangen Schritte 10 bis 12 sind Standardschritte
eines Softwareerstellungsprozesses. Die Durchführung der zuvor dargelegten
Schritte 2 bis 9 basiert demgegenüber ganz
essentiell auf der gemäß der Erfindung
entwickelten Fehlerklassifikation. Im Besonderen erlaubt die Fehlerklassifikation:
- – Die
Definition von Zielvorgaben auf einer allgemeinen, abstrakten Ebene,
die durch die Klassifikation vorgegeben ist und welche dazu geeignet ist,
von Teilprojektleitern bzw. Qualitätsverantwortlichen verstanden
zu werden.
- – Die
systematische Gesamtbeurteilung des Softwarequellcodes in einer
Art und Weise, dass Aussagen darüber
gemacht werden können,
welche technischen Problembereiche ganz besonders gut oder ganz
besonders schlecht zu bewerten sind. Diese Aggregation, die automatisch
einhergeht mit der Beurteilung der Softwarequalität, erleichtert
auch die Maßnahmenplanung
wesentlich.
- – Den
leichteren Vergleich von Soll-Qualität und Ist-Qualität des betrachteten Softwarequellcodes, da
der Vergleich nicht auf der Ebene einzelner Metriken erfolgen muss,
sondern systematisch auf höherer
Ebene durch die entsprechende Klassifikation festgelegt wird.
- – Die
Erstellung von Änderungsmitteilungen
an die Verantwortlichen, weil eventuelle Lösungshinweise schon ganz allgemein
zu einer Problemklasse zugeordnet werden können und nicht der einzelnen
Metrik bzw. den einzelnen Regeln zugeordnet werden müssen.
-
Durch
die soeben beschriebene Ausführungsform
des erfindungsgemäßen Verfahrens
wird eine automatisierte Verbesserung der Qualität eines Softwarequellcodes
mittels eines gezielten Be handelns von im Softwarequellcode enthaltenen
Fehlern erreicht. Dabei sind verschiedene Fehlerklassen vorgegeben,
und diesen Fehlerklassen sind Detektionsmechanismen zum Detektieren
der Fehler zugeordnet. Der Softwarequellcode wird mittels der Detektionsmechanismen überprüft, und
dabei detektierte Fehler werden einer Fehlerklasse zugeordnet. Erfindungsgemäß können unterschiedliche
Arten von im Softwarequellcode enthaltenen Fehlern systematisch und
effizient detektiert und behandelt werden. Das Verfahren reduziert
durch den erhöhten
Automatisierungsgrad und die Fokussierbarkeit auf die kritischen technischen
Aspekte den Aufwand für
die Steuerung der Softwarecodequalität erheblich. Es bildet eine Brücke von
den Fehler-Detektionsverfahren der klassischen Codeanalyse zu gezielten
Verbesserungsmaßnahmen,
welche die Codequalität
effizient erhöhen.
-
2 zeigt
ein Ausführungsbeispiel
einer Vorrichtung, mit der das erfindungsgemäße Verfahren realisiert werden
kann. Die Vorrichtung umfasst Benutzerschnittstellen, welche in
einer Präsentationsschicht
PL zusammengefasst sind. Beispiele solcher Benutzerschnittstellen,
mit denen die Ergebnisse des erfindungsgemäßen Verfahrens angezeigt werden,
sind Laptops LP, eine Workstation WS sowie ein Drucker P. Die Benutzerschnittstellen
Wechselwirken mit verschiedenen Modulen, die zu einer Anwendungsschicht
AL zusammengefasst wird. Es ist hierbei ein Modul M1 vorgesehen,
der einen Reportgenerator darstellt. Dieses Modul liefert als Ergebnis die
gemäß der Erfindung
erstellten Änderungsmitteilungen.
Darüber
hinaus ist ein Interaktionsmodul M2 vorgesehen, welche die Schnittstelle
zur Präsentationsschicht
PL darstellt. Das eigentliche erfindungsgemäße Verfahren, d.h. die Klassifikation
der Fehler erfolgt im Modul M3, welches einen Bewerter darstellt.
Im Modul M5 erfolgt der Vergleich zwischen der ermittelten Soll-Qualität und der
Ist-Qualität.
Darüber hinaus
ist ein Statistikmodul M7 vorgesehen, welches statistische Auswertungen
bezüglich
der gefundenen Fehler durchführt.
Ferner ist eine Datenschnittstelle als Modul M6 vorgesehen, welches
eine Schnittstelle hin zu der nachfolgend erläuterten Datenschicht DL darstellt.
Darüber
hinaus ist als zentrales Modul M4 in der Anwendungsschicht AL eine Steuereinheit
vorgesehen, welche die Interaktion zwischen den anderen Modulen
steuert.
-
Die
Datenschicht DL beinhaltet die im erfindungsgemäßen Verfahren verarbeiteten
bzw. erzeugten Daten. Beispielhaft sind drei Datensätze D1, D2
und D3 angegeben. In der hier beschriebenen Ausführungsform ist der Datensatz
D1 ein CM-System
(CM = Configuration-Management), welches ein projektspezifisches
Datensystem zur Verwaltung des betrachteten Softwareprojektes ist.
Ferner ist als Datensatz D2 eine Methodenverwaltung vorgesehen, welche
die Methoden der Klassifikation und Fehlerdetektion verwaltet. Dieser
Datensatz ist organisationsspezifisch, jedoch projektübergreifend.
Ferner ist in der Datenschicht DL die Qualitätshistorie D3 der früheren Softwareversionen
enthalten. Die Qualitätshistorie
D3 ist organisations- und projektübergreifend.