Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD AND DEVICE FOR AUTOMATICALLY EVALUATING A SOFTWARE SOURCE CODE QUALITY
Document Type and Number:
WIPO Patent Application WO/2007/028676
Kind Code:
A2
Abstract:
The invention relates to a method and device (1) for automatically evaluating a software source code (10) quality, wherein evaluation rules and/or metrics for evaluating the software source code (1) are pre-set (2). The source code (1) is inspected (3) with the aid of a set of evaluation rules and/or metrics, wherein said set contains at least one part of pre-set evaluation rules and/or metrics. In addition, the set of evaluation rules and/or metrics used for inspecting the source code (1) is adapted (6) according to the evaluation (4, 5) of an performed inspection of the source code (1) with respect to at least one predefined criterion for forming (8) an adapted set of evaluation rules and/or metrics different from the first set. In addition, the source code (1) is inspected (3) by means of the adapted set of evaluation rules and/or metrics. Said invention makes it possible to evaluate advantageously and automatically a large number of source codes with respect to the quality and the improvement thereof and to adapt the set of evaluation rules and/or metrics and, thereby the quality inspection to specific requirements, for example, related to projects. The invention makes it possible to carry out a modern control of the internal software quality taking into consideration a business model and requirements related to the internal software quality or the quality of use. Modifications and extensions necessary for a software development process can be taken into consideration in a particularly flexible manner.

Inventors:
BLASCHEK GUENTHER (AT)
KOERNER CHRISTIAN (DE)
PLOESCH REINHOLD (AT)
POMBERGER GUSTAV (AT)
SCHIFFER STEFAN (AT)
STORCK STEPHAN (US)
Application Number:
PCT/EP2006/064844
Publication Date:
March 15, 2007
Filing Date:
July 31, 2006
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SIEMENS AG (DE)
BLASCHEK GUENTHER (AT)
KOERNER CHRISTIAN (DE)
PLOESCH REINHOLD (AT)
POMBERGER GUSTAV (AT)
SCHIFFER STEFAN (AT)
STORCK STEPHAN (US)
International Classes:
G06F11/36
Other References:
SCHNEIDEWIND ET AL.: "IEEE Standard for a Software Quality Metrics Methodology", IEEE STD, 12 March 1993 (1993-03-12), pages 1061 - 1992
GULLA B. ED; KELLNER M.: "Software Maintenance, 1992, Proc. Conf. on Orlando", 9 November 1992, IEEE COMPUT. SOC., article "Improved Maintenance support by multi-version visualizations", pages: 376 - 383
"Software engineering-Product quality - Part 2: External metrics", ISO/IEC TECHNICAL REPORT, 1 July 2003 (2003-07-01), pages 9126 - 2
ROCHE; JACKSON; SHEPPERD: "Software Measurement Methods: An Evaluation and Perspective", PROCEEDINGS OF 3RD SYMPOSIUM ON ASSESSMENTS OF QUALITY SOFTWARE DEVELOPMENT TOOLS, 7 June 1994 (1994-06-07), pages 50 - 69
RAMOS C. S. ET AL.: "Legacy Software Evaluation Model for Outsourced Maintainer", SOFTWARE MAINTENANCE AND REENGINEERING, 2004, pages 48 - 57
Attorney, Agent or Firm:
SIEMENS AKTIENGESELLSCHAFT (München, DE)
Download PDF:
Claims:
Patentansprüche

1. Verfahren zum automatisierten Bewerten der Qualität eines Software-Quellcodes (1) , bei dem Bewertungsregeln und/oder Metriken zum Beurteilen der Qualität des Quellcodes (1) vorgegeben sind (2) und das Verfahren die folgenden Schritte aufweist :

überprüfen (3) des Quellcodes (1) mittels eines Satzes von Bewertungsregeln und/oder Metriken, wobei der Satz wenigs- tens einen Teil der vorgegebenen Bewertungsregeln und/oder Metriken aufweist,

Anpassen (6) des zum überprüfen des Quellcodes (1) eingesetzten Satzes von Bewertungsregeln und/oder Metriken in Abhängigkeit von einem Bewerten (4, 5) des durchgeführten ü- berprüfens des Quellcodes (1) hinsichtlich wenigstens eines vorgegebenen Kriteriums, um einen angepassten Satz von Bewertungsregeln und/oder Metriken zu bilden (8), der von dem Satz verschieden ist, und überprüfen (3) des Quellcodes (1) mittels des angepassten Satzes von Bewertungsregeln und/oder Metriken.

2. Verfahren nach Anspruch 1, da du r c h ge ke nn z e i c hn e t , dass das Anpassen (6) des zum überprüfen des Quellcodes (1) eingesetzten Satzes von Bewertungsregeln und/oder Metriken und das überprüfen (3) des Quellcodes mittels des angepassten Satzes von Bewertungsregeln und/oder Metriken wiederholt wird, bis ein vorgegebener Zustand für das wenigstens eine vorgegebene Kriterium erreicht ist.

3. Verfahren nach Anspruch 1 oder 2, da du r c h ge ke nn z e i c hn e t , dass das wenigstens eine vorgegebene Kriterium beim Bewerten (4, 5) des durchgeführten überprüfens des Quellcodes (1) ein Kriterium eines erreichten Automatisierungsgrades, ein Kriterium einer erreichten Abdeckung des Quellcodes (1) beim überprüfen und/oder ein Kriterium einer erreichten Abdeckung

eines zugrunde liegenden vorgegebenen Qualitätsmodells beim überprüfen enthält.

4. Verfahren nach wenigstens einem der vorstehenden Ansprü- che, dadurch gekennzeichnet, dass der Satz von Bewertungsregeln und/oder Metriken in Abhängigkeit von einem vorgegebenen Qualitätsmodell mit mehreren Qualitätsmerkmalen festgelegt wird (10) .

5. Verfahren nach wenigstens einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass eine Gesamt-Qualitätsbewertung der Qualität des Quell- codes (1) mittels einzelner Qualitätsbewertungen festgelegt wird (9) , die auf dem überprüfen des Quellcodes (1) mittels der einzelnen Bewertungsregeln und/oder Metriken des zum ü- berprüfen verwendeten Satzes basieren.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Gesamt-Qualitätsbewertung einer Qualitätshistorie hinzugefügt wird (13) , in der die Gesamt-

Qualitätsbewertungen verschiedener Versionen des Quellcodes (1, 17) enthalten sind.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass bei einem Anpassen (6) des Satzes von Bewertungsregeln und/oder Metriken, insbesondere in demjenigen Fall, in dem neue Bewertungsregeln und/oder Metriken dem Satz hinzugefügt wurden, eine in der Qualitätshistorie enthaltene Gesamt- Qualitätsbewertung für eine andere Quellcodeversion in Abhängigkeit von der Anpassung der Bewertungsregeln und/oder Metriken verändert wird (13) .

8. Verfahren nach wenigstens einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass ein dynamischer Test während des Ausführens der Soft- wäre durchgeführt wird (14), um eine Auswirkung einer auf einen detektierten Qualitätsmangel hin vorgenommenen Korrektur des Quellcodes (1) zu überprüfen und/oder eine Durchführung von mehreren Korrekturen zu priorisieren.

9. Vorrichtung (20) zum automatisierten Bewerten der Qualität eines Software-Quellcodes (1) , wobei Bewertungsregeln und/oder Metriken zum Beurteilen der Qualität des Quellcodes vorgegeben sind (2) und die Vorrichtung ein Steuermittel (23) aufweist, das so ausgestaltet ist, dass es Folgendes ermöglicht:

überprüfen (3) des Quellcodes (1) mittels eines Satzes von Bewertungsregeln und/oder Metriken, wobei der Satz wenigstens einen Teil der vorgegebenen Bewertungsregeln und/oder Metriken aufweist, Anpassen (6) des zum überprüfen des Quellcodes (1) eingesetzten Satzes von Bewertungsregeln und/oder Metriken in Abhängigkeit von einem Bewerten (4, 5) des durchgeführten ü- berprüfens des Quellcodes (1) hinsichtlich wenigstens eines vorgegebenen Kriteriums, um einen angepassten Satz von Be- wertungsregeln und/oder Metriken zu bilden (8), der von dem Satz verschieden ist, und

überprüfen (3) des Quellcodes (1) mittels des angepassten Satzes von Bewertungsregeln und/oder Metriken.

Description:

Beschreibung

Verfahren und Vorrichtung zum automatisierten Bewerten der Qualität eines Software-Quellcodes

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum automatisierten Bewerten der Qualität eines Software- Quellcodes .

Die Verbesserung der Qualität von Softwarecode ist ein ständiges Bestreben bei der Entwicklung von Software, d. h. Programmen für Computer. Dies gilt nicht nur in Bezug auf das Sicherstellen der Funktionalität der Software, sondern beispielsweise auch in Bezug auf deren Wartbarkeit und Portabi- lität. Eine ausreichend gute Qualität von Software ist insbesondere dann schwierig zu erreichen, wenn die Menge des Quellcodes groß ist - was jedoch erforderlich ist, um die gewünschte Funktionalität abzudecken. Darüber hinaus ist häufig eine große Menge an expliziten und impliziten infor- mellen Anforderungen vorhanden, die den beteiligten Entwicklern nicht in gleichem Maße bekannt sind und daher bei der Entwicklung nicht ausreichend berücksichtigt werden. Weiterhin ist häufig der Zeitdruck groß, um die Software fertig zu stellen und auszuliefern.

Zum Beurteilen der Qualität der Software wurden bereits Qualitätsmodelle entwickelt, mit denen sich die Qualität nach vorgegebenen Kriterien beurteilen lässt. Ein solches Qualitätsmodell enthält beispielsweise die Deutsche Industrie Norm, DIN, ISO 9126, Informationstechnik - Beurteilen von

Softwareprodukten, Qualitätsmerkmalen und Leitfaden zu deren Verwendung, 1991. In dieser Norm werden neben den Qualitätsmerkmalen auch Metriken definiert, mit denen die Qualität der Software gemessen und angegeben werden soll. über diese Norm hinaus sind im Folgenden Beispiele für objektorientierte Metriken aufgeführt: Depth of Inheritance Tree, DIT, Number of Children, NOC, Coupling between Objects, CBO,

Weighted Methods per Class, WMC, Response for Class, RFC, Message Passing Coupling, MPC, Lack of Cohesion in Methods, LCOM, etc. Mit diesen Metriken lassen sich insbesondere Eigenschaften von objekt-orientierter Software auf der Ebene von Klassen und Methoden messen.

Metriken sind Indikatoren für in der Software enthaltene Fehler und häufig nur beschränkt aussagekräftig. Sie sind abhängig von den technischen Randbedingungen der verwendeten Computersysteme, wie Speicherkapazitäten, Reaktionszeiten, Durchsätzen, etc und von impliziten Erfordernissen der Anwendungsdomäne, z.B. einem Echtzeitsystem. Für eine zuverlässige Beurteilung der Softwarequalität ist es daher notwendig, die Qualität der Software zusätzlich von Experten beurteilen zu lassen, die zumindest Teile des Quellcodes mehr oder weniger strukturiert manuell durchlesen. Dabei werden potentielle Fehlerquellen erörtert, dokumentiert und Verbesserungsmöglichkeiten vorgeschlagen, die dann vorzugsweise zur Korrektur der Fehler in der Software führen. Die- ses Vorgehen ist allerdings aufgrund von schnell wachsenden Mengen an Quellcode, hoher Vernetzung der Systeme mit ihrem jeweiligen Anwendungsumfeld, kurzen Entwicklungszeiten, häufig örtlich verteilten Entwicklungskapazitäten und nicht zuletzt Expertenmangel zunehmend unpraktikabel und fehleran- fällig.

Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein automatisiertes Bewerten einer Qualität einer Software auf einfache Weise zu ermöglichen.

Erfindungsgemäß wird diese Aufgabe durch ein Verfahren oder eine Vorrichtung zum automatisierten Bewerten der Qualität eines Software-Quellcodes mit den Merkmalen des Patentanspruches 1 bzw. 9 gelöst.

Verfahrensseitig sind Bewertungsregeln und/oder Metriken zum Beurteilen der Qualität des Quellcodes vorgegeben. Der

Quellcode, insbesondere dessen Qualität, wird mittels eines Satzes von Bewertungsregeln und/oder Metriken überprüft, wobei der Satz wenigstens einen Teil der vorgegebenen Bewertungsregeln und/oder Metriken aufweist. Anschließend wird der zum überprüfen des Quellcodes eingesetzte Satz von Bewertungsregeln und/oder Metriken in Abhängigkeit von einem Bewerten des durchgeführten überprüfens des Quellcodes hinsichtlich wenigstens eines vorgegebenen Kriteriums überprüft, um einen angepassten Satz von Bewertungsregeln und/oder Metriken zu bilden, der von dem Satz verschieden ist. Des Weiteren wird dann der Quellcode mittels des angepassten Satzes von Bewertungsregeln und/oder Metriken überprüft .

Vorrichtungsseitig sind Bewertungsregeln und/oder Metriken zum Beurteilen der Qualität des Quellcodes vorgegeben und es ist ein Steuermittel vorhanden, das so ausgestaltet ist, dass es ein überprüfen des Quellcodes mittels eines Satzes von Bewertungsregeln und/oder Metriken ermöglicht, wobei der Satz wenigstens einen Teil der vorgegebenen Bewertungsregeln und/oder Metriken aufweist. Des Weiteren ist das Steuermittel so ausgestaltet, dass es ein Anpassen des zum überprüfen des Quellcodes eingesetzten Satzes von Bewertungsregeln und/oder Metriken steuert. Dies erfolgt in Abhängigkeit von einem Bewerten des durchgeführten überprüfens des Quellcodes hinsichtlich wenigstens eines vorgegebenen Kriteriums. Das Ergebnis ist ein angepasster Satz von Bewertungsregeln und/oder Metriken, der von dem Satz verschieden ist. Zusätzlich ermöglicht das Steuermittel ein überprüfen des Quellco- des mittels des angepassten Satzes von Bewertungsregeln und/oder Metriken. Das Steuermittel ist dabei insbesondere so ausgestaltet, dass es ein Ausführen des erfindungsgemäßen Verfahrens ermöglicht.

Erfindungsgemäß ist eine Vielzahl von unterschiedlichen Bewertungsregeln und/oder Metriken als Qualitätsindikatoren vorgegeben, mit denen die Qualität von unterschiedlichen

Software-Quellcodes bewertet und Fehlerquellen und Probleme im Quellcode detektiert werden können. Durch das Bilden des Satzes von Bewertungsregeln und/oder Metriken ist es möglich, das überprüfen der Qualität individuell auf den Zweck und die gewünschte Funktionalität der Software abzustimmen. Es kann somit ein projektspezifischer Regel- und Metrikensatz erstellt werden. In die Bewertungsregeln lassen sich insbesondere auch Korrektheitsbeweise einbinden, sofern solche für spezielle Algorithmen existieren.

Erfindungsgemäß erfolgt somit ein Hinleiten des Entwickeins der Software auf das Qualitätsziel durch ein Vorgeben und geeignetes Anpassen des Satzes von Bewertungsregeln und/oder Metriken und vorteilhafterweise von Grenzwerten für das Bestimmen der Bewertungsregeln und/oder Metriken.

Gemäß der vorliegenden Erfindung kann vorteilhafterweise eine zielgerichtete Steuerung der Bewertung und insbesondere auch einer Verbesserung der Qualität des Quellcodes ermög- licht werden. Das Bewerten der Qualität erfolgt zuverlässig, wiederholbar und kann vor allem bei großen bis sehr großen Softwaresystemen vorteilhaft eingesetzt werden. Eine Sicherung und Steuerung der internen Qualität der Software, d. h. der Qualität während des Erstellens des Quellcodes, der An- forderungen und der Kommentare, und indirekt auch der externen Qualität, d. h. der Qualität der lauffähigen Software, kann auf effektive Weise gewährleistet werden. Aufgrund des hohen Automatisierungsgrades können erstellte Versionen des Quellcodes zeitnah zur Erstellung und mit begrenztem techni- schem und wirtschaftlichem Aufwand überprüft werden. Es wird somit eine schnelle, zielgerichtete Entscheidungshilfe zum Beurteilen der Qualität und insbesondere auch zum Aufzeigen von Fehlern und auch von Verbesserungsmöglichkeiten zur Verfügung gestellt.

Das Anpassen des zum überprüfen des Quellcodes eingesetzten Satzes von Bewertungsregeln und/oder Metriken und das über-

prüfen des Quellcodes mittels des angepassten Satzes von Bewertungsregeln und/oder Metriken wird vorteilhafterweise wiederholt, bis ein vorgegebener Zustand für das wenigstens eine Kriterium erreicht ist. Der Satz von Bewertungsregeln und/oder Metriken wird somit angepasst, so dass sukzessive und iterativ die Zusammenstellung der Bewertungsregeln und/oder Metriken in dem (angepassten) Satz optimiert werden kann. Dies erfolgt im Hinblick auf das wenigstens eine vorgegebene Kriterium, das z. B. von einem Anforderungsprofil für das Erstellen der Software vorgegeben sein kann.

In einer weiteren, besonders bevorzugten Ausgestaltung der Erfindung enthält das wenigstens eine vorgegebene Kriterium beim Bewerten des durchgeführten überprüfens des Quellcodes ein Kriterium eines erreichten Automatisierungsgrades, ein Kriterium einer erreichten Abdeckung des Quellcodes beim ü- berprüfen und/oder ein Kriterium einer erreichten Abdeckung eines zugrunde liegenden vorgegebenen Qualitätsmodells beim überprüfen. Das Qualitätsmodell kann insbesondere auf der Grundlage eines bestimmten Geschäftsmodells für die Software festgelegt sein. Dies bedeutet, dass das Qualitätsmodell z. B. aus der Lebensdauer und dem Einsatzfeld der Software oder des Produktes, in dem die Software eingesetzt ist, abgeleitet ist. Durch diese Kriterien kann der Satz von Bewertungs- regeln und/oder Metriken besonders gut, insbesondere an bestehende Ressourcen und Ziele, wie z. B. Projektziele, ange- passt werden.

Besonders bevorzugt wird der Satz von Bewertungsregeln und/oder Metriken in Abhängigkeit von einem vorgegebenen

Qualitätsmodell mit mehreren Qualitätsmerkmalen festgelegt. Qualitätsmerkmale eines solchen Qualitätsmodells können beispielsweise Wartbarkeit, Komplexität, Zuverlässigkeit, Benutzbarkeit, Effizienz, übertragbarkeit, Verständlichkeit, Produktivität, Sicherheit, Analysierbarkeit und/oder Effektivität des Quellcodes sein. Vorteilhafterweise werden solche Qualitätsmerkmale des Qualitätsmodells für das überprü-

fen verwendet, die durch statische Analysemethoden untersucht werden können. Die einzelnen Bewertungsregeln und/oder Metriken können dabei vorteilhafterweise bestimmten Qualitätsmerkmalen zugeordnet sein.

Gemäß einer bevorzugten Weiterbildung der Erfindung wird eine Gesamt-Qualitätsbewertung der Qualität des Quellcodes mittels einzelner Qualitätsbewertungen festgelegt, die auf dem überprüfen des Quellcodes mittels der einzelnen Bewer- tungsregeln und/oder Metriken des zum überprüfen verwendeten Satzes basieren. Die Gesamt-Qualitätsbewertung und die einzelnen Qualitätsbewertungen können jeweils durch Kennzahlen repräsentiert sein. Dadurch kann die Qualität vorteilhafterweise übersichtlich dargestellt und schnell erfasst werden. Des Weiteren ist es auf einfache Weise möglich, die jeweilige Qualitätsbewertung zur Problemanalyse einzusetzen und zum Verbessern der Qualität der Software zu verwenden.

Besonders bevorzugt wird die Gesamt-Qualitätsbewertung einer Qualitätshistorie hinzugefügt, in der die Gesamt-

Qualitätsbewertungen verschiedener Versionen des Quellcodes enthalten sind. Für die verschiedenen Versionen entsteht somit eine Folge von miteinander vergleichbaren Qualitätsbewertungen. Diese Folge von Qualitätsbewertungen kann vor- teilhafterweise statistisch ausgewertet werden, um beispielsweise in Form einer Trendanalyse systematische oder sporadische Fehlerquellen zu identifizieren. Dies kann insbesondere für das Projekt spezifische Schwächen des Codes betreffen, die dadurch sichtbar gemacht werden und ein di- rektes Gegensteuern ermöglichen.

In einer weiteren, besonders bevorzugten Ausgestaltung der Erfindung wird bei einer Anpassung des Satzes von Bewertungsregeln und/oder Metriken, insbesondere in demjenigen Fall, in dem neue Bewertungsregeln und/oder Metriken dem

Satz hinzugefügt wurden, eine in der Qualitätshistorie enthaltene Gesamt-Qualitätsbewertung für eine andere Quellcode-

version in Abhängigkeit von der Anpassung der Bewertungsregeln und/oder Metriken verändert. Dies trägt vorteilhafterweise dazu bei, diesbezügliche negative Trends schon beim Erstellen des Quellcodes frühzeitig erkennen und abstellen zu können. Das Anpassen der Gesamt-Qualitätsbewertungen muss nicht notwendigerweise für alle Versionen der Software erfolgen. Vielmehr reicht es je nach Anwendung aus, ausgewählte Versionen einer Gesamtbeurteilung zu unterziehen.

Gemäß einer weiteren, bevorzugten Weiterbildung der Erfindung wird ein dynamischer Test während des Ausführens der Software durchgeführt, um eine Auswirkung einer auf einen detektierten Qualitätsmangel hin vorgenommenen Korrektur des Quellcodes zu überprüfen und/oder eine Durchführung von meh- reren Korrekturen zu priorisieren. Dies erfolgt insbesondere sofern Auffälligkeiten in der Qualitätshistorie vorhanden sind, für die mittels Detailanalysen Korrekturmöglichkeiten identifiziert werden sollen. Mittels des dynamischen Tests kann der Einfluss der Korrekturmöglichkeit auf den Code ana- lysiert werden. Darüber hinaus kann bei mehreren vorhandenen Korrekturmöglichkeiten deren Durchführung priorisiert werden. Beispielsweise hilft der dynamische Test in dem Fall, in dem bei einer Regelverletzung sichergestellt werden soll, dass diese Regel im Quellcode eingehalten wird, die Korrek- turen auf die am häufigsten verwendeten Stellen des Quellcodes zu fokussieren oder zu priorisieren. Des Weiteren kann beispielsweise bei einer Verletzung einer Längenmetrik, wie z. B. der Längenmetrik "Anzahl der Anweisungen eines Moduls", der Verletzung einer Komplexitätsmetrik, wie z. B. der Komplexitätsmetrik "Anzahl unabhängiger Pfade", oder der Verletzung einer anderen kontextabhängigen Metrik der dynamische Test die konkreten Auswirkungen der jeweiligen Verletzung auf die Software erfassen. Dieses Erfassen kann vor allem hinsichtlich der Größe des geladenen Quellcodes im Hauptspeicher (Footprint) und/oder der Reaktivität der Software (Zeit für die Reaktion der Software auf eine Eingabe) erfolgen.

Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind der Beschreibung unter Bezugnahme auf die Zeichnung entnehmbar .

Die Erfindung wird nachfolgend anhand der in den schematischen Figuren der Zeichnung angegebenen Ausführungsbeispiele näher erläutert. Es zeigen dabei:

Figur 1 eine schematische Darstellung eines Ausführungsbeispieles eines erfindungsgemäßen Verfahrens zum automatisierten Bewerten der Qualität eines Software- Quellcodes und

Figur 2 eine schematische Darstellung eines Ausführungsbeispieles einer erfindungsgemäßen Vorrichtung zum automatisierten Bewerten der Qualität eines Software- Quellcodes .

Fig. 1 zeigt schematisch ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens zum automatisierten Bewerten der Qualität eines Software-Quellcodes . Ausgangspunkte für die Durchführung des Verfahrens sind der zu bewertende und zu verbessernde Quellcode, der in der Fig. 1 durch die Verfah- renskomponente mit dem Bezugszeichen 1 repräsentiert ist. Eine Verfahrenskomponente 2 repräsentiert einen Bestand an Bewertungsregeln und Metriken, die für ein überprüfen des Quellcodes eingesetzt werden können. Die Bewertungsregeln sind dokumentiert, d. h. mit den Bewertungsregeln sind Att- ribute gespeichert, die eine Auswahl der Bewertungsregeln und Metriken ermöglichen oder unterstützen. Die Verfahrenskomponente 2 repräsentiert des Weiteren ein vorgegebenes Qualitätsziel, das eine gewünschte Qualität angibt, die die Software haben soll. Das Qualitätsziel basiert auf einem vorgegebenen Qualitätsmodell, dem eine Vielzahl von Qualitätsmerkmalen zugeordnet ist. Die Qualitätsmerkmale können mittels der Bewertungsregeln und Metriken überprüft und be-

urteilt werden. Dies bedeutet auch, dass Fehler oder Problemquellen im Quellcode, bei denen die Qualitätsmerkmale im Quellcode nicht eingehalten werden, mittels der Bewertungsregeln und Metriken aufgedeckt werden können. Eines der Qua- litätsmerkmale kann beispielsweise die Wartbarkeit des

Quellcodes sein. Die Wartbarkeit entspricht einem Ausmaß, in dem die Software, d. h. der Quellcode, geändert werden kann. Zu diesen änderungen zählen Korrekturen sowie Verbesserungen und Anpassungen an änderungen der Umgebung, der Anforderun- gen und/oder der funktionalen Spezifikation. Die Wartbarkeit kann durch weitere Kriterien, wie z. B. Einfachheit oder Lesbarkeit, weiter beschrieben werden. Die Einfachheit kann beispielsweise durch eine Metrik CBOR, "Hohe Kopplung durch Typ-Verwendung", beschrieben werden. Diese Metrik CBOR un- tersucht die Kopplung einer Klasse mit anderen Klassen. Eine Klasse, die mit vielen anderen Klassen gekoppelt ist, ist inhärent komplex, d. h. schwer zu verstehen, da zumindest ansatzweise auch alle verwendeten Klassen verstanden werden müssen, um die Klasse selbst verstehen zu können. Daher zählt diese Metrik CBOR pro Klasse die Anzahl unterschiedlicher Typen für Attribute, lokale Variablen und Rückgabewerte. Die Verfahrenskomponenten 1 und 2 repräsentieren somit vorgegebene Bedingungen zum Durchführen des erfindungsgemäßen Verfahrens .

Auf der Grundlage der vorgegebenen Bedingungen Quellcode, Qualitätsmodell, Bewertungsregeln und Metriken wird in einem Verfahrensschritt 3 mittels eines automatischen Quellcode- überprüfungs- und Metrikwerkzeuges der Quellcode mittels ei- nes Satzes der vorgegebenen Bewertungsregeln und Metriken überprüft. Der zum überprüfen verwendete Teil von vorgegebenen Bewertungsregeln und Metriken wird zuvor beispielsweise von einem Entwickler der Software oder einem Experten nach bestimmten, insbesondere projektspezifischen Kriterien aus- gewählt, so dass nur ein Teil der vorgegebenen Bewertungsregeln und Metriken eingesetzt wird. Es ist allerdings auch möglich, alle vorgegebenen Bewertungsregeln und Metriken zum

überprüfen einzusetzen. Im Verfahrensschritt 3 werden einzelne Qualitätsbewertungen festgelegt, die auf dem überprüfen des Quellcodes mittels der einzelnen Bewertungsregeln und/oder Metriken des zum überprüfen verwendeten Satzes ba- sieren. Die einzelnen Qualitätsbewertungen sind vorteil- hafterweise jeweils durch Kennzahlen repräsentiert. In einem Verfahrensschritt 4 wird ein überprüfen und Bewerten der Ergebnisse des überprüfungs-Verfahrensschrittes 3 vorgenommen. Dabei wird insbesondere geprüft, welche Bewertungsregeln und/oder Metriken abhängig von der Programmiersprache, der Anwendungsdomäne und dem Qualitätsziel notwendig und gültig sind. Dieses überprüfen kann automatisiert erfolgen. Alternativ oder zusätzlich ist auch ein überprüfen durch einen Experten vorteilhaft. In einem Verfahrensschritt 5 wird auf der Grundlage des Verfahrensschrittes 4 entschieden, ob wenigstens ein vorgegebenes Kriterium beim Bewerten des durchgeführten überprüfens des Quellcodes erfüllt ist. Ein solches kann insbesondere ein erreichter Automatisierungsgrad und/oder eine erreichte Abdeckung des Quellcodes beim über- prüfen sein. Ist das wenigstens eine Kriterium nicht erfüllt, so verzweigt das erfindungsgemäße Verfahren zu einem Verfahrensschritt 6. In diesem Verfahrensschritt 6 wird der Satz von Bewertungsregeln und/oder Metriken angepasst. Dies erfolgt abhängig von der im Verfahrensschritt 4 vorgenomme- nen überprüfung des Satzes von Bewertungsregeln und Metriken und der im Verfahrensschritt 5 vorgenommenen überprüfung des Erfülltseins des vorgegebenen Kriteriums. Das Anpassen des Satzes erfolgt projektspezifisch, so dass kontextrelevante, werkzeuggestützt prüfbare Bewertungsregeln und Metriken, die insbesondere der spezifischen Anwendung der Software entstammen, hinzugefügt und zuvor eingesetzte Bewertungsregeln und Metriken, die nicht anwendbar sind, nunmehr ausgeschlossen werden. Das Anpassen kann vorteilhafterweise durch Vorgabe von weiteren manuellen Bewertungsregeln, die insbeson- dere auf der Erfahrung eines Entwicklers oder Experten beruhen, erfolgen. Dies ist in der Fig. 1 durch einen Verfahrensschritt 7 dargestellt. Durch das Anpassen im Verfahrens-

schritt 6 entsteht ein angepasster Satz von Bewertungsregeln und Metriken. Dies ist durch einen Verfahrensschritt 8 angegeben. Das erfindungsgemäße Verfahren verzweigt anschließend erneut zu dem Verfahrensschritt 3, in dem der Quellcode mit- tels des angepassten Satzes von Bewertungsregeln und Metriken und des automatischen Quellcode-überprüfungs- und Metrikwerkzeuges geprüft wird. Die durch die Verfahrensschritte 3, 4, 5, 6 und 8 gegebene Schleife wird solange durchlaufen, bis in dem Verfahrensschritt 5 festgestellt wird, dass das wenigstens eine vorgegebene Kriterium erfüllt ist.

Ist dies der Fall, so verzweigt das Verfahren von dem Verfahrensschritt 5 zu einem Verfahrensschritt 9, in dem die Ergebnisse der im Verfahrensschritt 3 durchgeführten über- prüfung auf der Basis des zugrunde liegenden Qualitätsmodells zusammengefasst werden. Vor dem Durchführen des Verfahrensschrittes 9 können in einem Verfahrensschritt 10 neue Bewertungsregeln und Metriken in dem Qualitätsmodell ergänzt werden. Des Weiteren kann die Bewertung der Bewertungsregeln und Metriken entsprechend des Qualitätszieles angepasst werden. Das Zusammenfassen der Ergebnisse im Verfahrensschritt 9 erfolgt auf solche Weise, dass eine Gesamt- Qualitätsbewertung der Qualität des Quellcodes festgelegt wird, indem die in dem Verfahrensschritt 3 erzeugten einzel- nen Qualitätsbewertungen für die einzelnen Bewertungsregeln und/oder Metriken auf geeignete Weise zusammengefasst werden. Dazu kann eine Abbildungsfunktion definiert sein, mit der die einzelnen Qualitätsbewertungen für die einzelnen Bewertungsregeln und/oder Metriken gewichtet miteinander ver- knüpft sind. Die Gesamt-Qualitätsbewertung ist ebenfalls einfachheitshalber durch eine Kennzahl repräsentiert. In einem weiteren Verfahrensschritt 11 kann die im Verfahrensschritt 9 vorgenommene Zusammenfassung der Bewertung zu der Gesamt-Qualitätsbewertung von dem Experten insbesondere auf der Grundlage einer Plausibilitätsprüfung überprüft werden. In einem Verfahrensschritt 12 steht dann eine endgültige Bewertung dieser aktuellen Version der Software zur Verfügung.

Bei dieser Qualitätsbewertung der aktuellen Version der Software sind die automatisiert erstellten einzelnen Bewertungen der Qualität der Software vorteilhafterweise zusätzlich durch die Expertenprüfung abgesichert, was eine hohe Zuverlässigkeit der Bewertung gewährleistet.

Die endgültige Bewertung wird in einem Verfahrensschritt 13 einer Qualitätshistorie hinzugefügt. In dieser Qualitätshistorie sind Gesamt-Qualitätsbewertungen verschiedener Versio- nen des Quellcodes enthalten. Die Entwicklung der Software, und insbesondere der Aufbau ihrer Funktionalität, erfolgt versionsweise. Dies bedeutet hier, dass die verschiedenen Versionen aufeinander aufbauen und üblicherweise eine neue Version die Funktionalität, Leistung und Qualität einer Vor- gängerversion verbessert. Da die zusammengefassten Bewertungen der verschiedenen Versionen der Software in der Qualitätshistorie enthalten sind, ist es möglich, diese Folge von Qualitätsbewertungen miteinander zu vergleichen. Dies erfolgt im Verfahrensschritt 13. Zusätzlich werden im vorlie- genden Ausführungsbeispiel auf in der Qualitätshistorie enthaltene Qualitätsbewertungen älterer Vorgängerversionen im Laufe des überprüfens neuerer Versionen hinzugekommene Bewertungsregeln oder Metriken angewendet. Dadurch werden diese Vorgängerversionen ebenfalls mittels dieser neuen Regeln oder Metriken untersucht, so dass weitere einzelne Qualitätsbewertungen entstehen, die zusätzlich für die Beurteilung von bestimmten Trends bei der Entwicklung der Software eingesetzt werden können.

Das Ergebnis des Vergleiches in Verfahrensschritt 13 und die Auswertung der Qualitätshistorie können dann für die gezielte Verbesserung der Qualität der Software eingesetzt werden. Dazu werden dann in einem Verfahrensschritt 14 bei Auffälligkeiten in der Qualitätshistorie Korrekturmöglichkeiten identifiziert. Dies erfolgt mittels Analysen von Details der Software. Dazu können zusätzlich dynamische Tests während des Betriebes der Software durchgeführt werden, um den Ein-

fluss von bestimmten Korrekturen auf die Qualität der Software festzustellen. Bei den dynamischen Tests wird die Software parametriert und das Testsystem erstellt, um die konkrete Bewertungskennzahl für die korrigierte Software fest- stellen zu können. Im Verfahrensschritt 14 kann ebenfalls das Durchführen von mehreren Korrekturmöglichkeiten priori- siert werden. Beim Anwenden von Regeln, die widersprüchlichen Randbedingungen Rechnung tragen, ist vorzugsweise eine Vorgehensweise zu wählen, die sicherstellt, dass vorgenomme- ne änderungen gegen das generelle Qualitätsziel konvergieren. Das Steuern der Qualität der Software mittels Identifizieren und Testen der Korrekturmöglichkeiten kann mittels einer vorhandenen Lösungsbibliothek unterstützt werden. Dies ist in der Fig. 1 durch den Verfahrensschritt 15 darge- stellt. In einem Verfahrensschritt 16 werden dann identifizierte Korrekturmöglichkeiten in den Quellcode eingearbeitet, um die Software zu verbessern und zu erweitern. Bei einer zuvor vorgenommenen Priorisierung der Korrekturmöglichkeiten werden diese entsprechend ihrer Priorität eingearbei- tet . Im Verfahrensschritt 17 steht dann eine verbesserte neue Softwareversion zur Verfügung. Diese wird dann dem bereits zuvor bei Verfahrensschritt 3 beschriebenen automatischen Quellcode-überprüfungs- und Metrikwerkzeug zugeleitet. Die Prüfung der neuen Softwareversion erfolgt dann auf die oben beschriebene Weise.

Aufgrund der Erfindung ist es vorteilhafterweise möglich, auf einfache Weise und mit ausreichend genauem und wirtschaftlich vertretbarem Aufwand eine automatisierte Bewer- tung der aktuellen Qualität des Software-Quellcodes vorzunehmen. Das Verknüpfen von automatisierten Quellcode- überprüfungen und das Zusammenfassen deren Ergebnisse auf der Grundlage des zugrunde liegenden Qualitätsmodells zu einer quantifizierten, insbesondere in dem speziellen Projekt vergleichbaren Gesamtaussage ermöglicht eine besonders effektive und einfach zu veranschauende Qualitätsbewertung und -Verbesserung. Projektspezifische Schwächen können durch

Qualitätsvergleiche, insbesondere mittels der Qualitätshistorie, sichtbar gemacht und zielgerichtet ausgeräumt werden.

Fig. 2 zeigt schematisch ein Ausführungsbeispiel einer er- findungsgemäßen Vorrichtung zum automatisierten Bewerten der Qualität eines Software-Quellcodes . Mit dieser Vorrichtung lässt sich das erfindungsgemäße Verfahren zum automatisierten Bewerten der Qualität eines Software-Quellcodes, wie es an Hand der Fig. 1 beschrieben wurde, ausführen. Die erfin- dungsgemäße Vorrichtung ist hier ein Computer 20. Der Computer 20 weist einen Bildschirm 21 und ein Eingabemittel auf, das hier eine Tastatur 22 ist. Der Computer 20 enthält des Weiteren eine Steuereinrichtung 23, die die Abläufe des Computers 20 und insbesondere das Ausführen des erfindungsgemä- ßen Verfahrens steuert. Die Steuereinrichtung 23 enthält insbesondere einen Prozessor und einen Speicher, in dem ein geeignetes Programm, d. h. eine Software, abgespeichert ist, das von dem Prozessor ausgeführt werden kann, um das erfindungsgemäße Verfahren durchzuführen. Die Steuereinrichtung 23 enthält einen Software-Speicher 24, in dem der Quellcode der Software abgespeichert ist, deren Qualität bewertet werden soll. Die Steuereinrichtung 23 greift somit während des Bewertens und überprüfens des Quellcodes auf den Speicher 24 zu.

Obgleich die vorliegende Erfindung vorstehend anhand bevorzugter Ausführungsbeispiele beschrieben wurde, ist sie darauf nicht beschränkt, sondern auf vielfältige Art und Weise modifizierbar .