WO2007028676A2 - Verfahren und vorrichtung zum automatisierten bewerten der qualität eines software-quellcodes - Google Patents

Verfahren und vorrichtung zum automatisierten bewerten der qualität eines software-quellcodes Download PDF

Info

Publication number
WO2007028676A2
WO2007028676A2 PCT/EP2006/064844 EP2006064844W WO2007028676A2 WO 2007028676 A2 WO2007028676 A2 WO 2007028676A2 EP 2006064844 W EP2006064844 W EP 2006064844W WO 2007028676 A2 WO2007028676 A2 WO 2007028676A2
Authority
WO
WIPO (PCT)
Prior art keywords
source code
metrics
quality
evaluation rules
rules
Prior art date
Application number
PCT/EP2006/064844
Other languages
English (en)
French (fr)
Other versions
WO2007028676A3 (de
Inventor
Günther BLASCHEK
Christian Körner
Reinhold PLÖSCH
Gustav Pomberger
Stefan Schiffer
Stephan Storck
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to EP06792612A priority Critical patent/EP1922613A2/de
Priority to US11/991,429 priority patent/US20090055804A1/en
Publication of WO2007028676A2 publication Critical patent/WO2007028676A2/de
Publication of WO2007028676A3 publication Critical patent/WO2007028676A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3616—Software analysis for verifying properties of programs using software metrics

Definitions

  • the invention relates to a method and an apparatus for the automated assessment of the quality of a software source code.
  • Improving the quality of software code is a constant endeavor in the development of software, i. H. Programs for computers. This applies not only to ensuring the functionality of the software, but also, for example, in terms of its maintainability and portability. Sufficiently good quality of software is particularly difficult to achieve when the amount of source code is large - which, however, is required to cover the desired functionality. In addition, there is often a large amount of explicit and implicit informal requirements that are not known to the same extent to the developers involved and are therefore not sufficiently considered in the development. Furthermore, the time pressure is often great to complete the software and deliver.
  • Such a quality model contains, for example, the German industry standard, DIN, ISO 9126, Information technology - Assessment of
  • this standard defines metrics that measure and report the quality of the software.
  • object-oriented metrics are listed below: 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. These metrics can be used to measure properties of object-oriented software at the level of classes and methods.
  • Metrics are indicators of software errors and often have limited meaning. They depend on the technical constraints of the computer systems used, such as storage capacities, response times, throughputs, etc., and on implicit requirements of the application domain, e.g. a real-time system. For a reliable assessment of the software quality, it is therefore necessary to additionally assess the quality of the software by experts who manually read at least parts of the source code in a more or less structured manner. In the process, potential sources of error are discussed, documented and suggestions for improvement are made, which then preferably lead to the correction of the errors in the software. However, this approach is increasingly impractical and prone to errors due to rapidly growing volumes of source code, high network interconnectivity of the systems with their respective application environment, short development times, often locally distributed development capabilities, and not least expert shortages.
  • the present invention has for its object to enable an automated assessment of a quality of software in a simple manner.
  • this object is achieved by a method or a device for the automated evaluation of the quality of a software source code having the features of patent claims 1 and 9, respectively.
  • evaluation rules and / or metrics for assessing the quality of the source code are prescribed.
  • the Source code in particular its quality, is checked by means of a set of evaluation rules and / or metrics, the sentence having at least part of the predetermined evaluation rules and / or metrics.
  • the set of validation rules and / or metrics used to validate the source code is examined in response to evaluating the source code's validation for at least one predetermined criterion to form an adjusted set of evaluation rules and / or metrics other than the set is.
  • the source code is then checked by means of the adjusted set of evaluation rules and / or metrics.
  • control means arranged to allow verification of the source code by means of a set of evaluation rules and / or metrics, the sentence covering at least part of the predetermined rating rules and / or metrics.
  • control means is arranged to control an adaptation of the set of evaluation rules and / or metrics used to verify the source code. This is done in response to an evaluation of the performed verification of the source code with respect to at least one predetermined criterion. The result is an adjusted set of evaluation rules and / or metrics that is different from the sentence.
  • the control means makes it possible to check the source code by means of the adapted set of evaluation rules and / or metrics.
  • the control means is in particular designed so that it allows an implementation of the method according to the invention.
  • a multiplicity of different evaluation rules and / or metrics are specified as quality indicators with which the quality of different Software source code rated and error sources and problems in the source code can be detected.
  • the software is guided to the quality goal by predetermining and appropriately adapting the set of evaluation rules and / or metrics and advantageously by limiting values for determining the evaluation rules and / or metrics.
  • a targeted control of the evaluation and in particular also an improvement of the quality of the source code can be made possible.
  • the rating of the quality is reliable, repeatable and can be used advantageously especially for large to very large software systems.
  • the quality of the executable software can be effectively guaranteed. Due to the high level of automation, created versions of the source code can be checked promptly for creation and with limited technical and economic effort. Thus, a fast, targeted decision-making aid is provided for assessing the quality and, in particular, also for pointing out errors and also for possibilities for improvement.
  • Adjusting the set of rating rules and / or metrics used to verify the source code, and the overlay Checking the source code using the adjusted set of evaluation rules and / or metrics is advantageously repeated until a predetermined state for the at least one criterion is reached.
  • the set of evaluation rules and / or metrics is thus adjusted so that the composition of the evaluation rules and / or metrics in the (adjusted) sentence can be optimized successively and iteratively. This is done with regard to the at least one predetermined criterion, the z. B. can be specified by a requirement profile for creating the software.
  • the at least one predefined criterion when evaluating the performed checking of the source code contains a criterion of an achieved degree of automation, a criterion of achieved coverage of the source code when verifying and / or a criterion of achieved coverage of an underlying given quality model when checking.
  • the quality model may be determined based on a particular business model for the software. This means that the quality model z. B. derived from the life and field of use of the software or the product in which the software is used.
  • the set of evaluation rules and / or metrics can be particularly well suited, in particular to existing resources and goals, such. Project goals.
  • Quality model set with several quality characteristics Quality features of such a quality model can be, for example, maintainability, complexity, reliability, usability, efficiency, portability, comprehensibility, productivity, security, analyzability and / or effectiveness of the source code.
  • quality features of the quality model for reviewing used which can be examined by static analysis methods.
  • the individual evaluation rules and / or metrics can advantageously be assigned to certain quality characteristics.
  • an overall quality assessment of the quality of the source code is determined by means of individual quality assessments which are based on checking the source code by means of the individual evaluation rules and / or metrics of the set used for checking.
  • the overall quality assessment and the individual quality assessments can each be represented by key figures.
  • the quality can advantageously be displayed clearly and quickly recorded.
  • the overall quality assessment is added to a quality history in which the overall
  • Quality ratings of various versions of the source code are included. For the different versions, this results in a sequence of comparable quality assessments.
  • This sequence of quality evaluations can advantageously be statistically evaluated in order to identify systematic or sporadic sources of error, for example in the form of a trend analysis. In particular, this can affect specific weaknesses of the code that are made visible by the code and enable direct countermeasures.
  • a dynamic test is carried out during the execution of the software in order to check the effect of a correction of the source code carried out for a detected quality defect and / or to prioritize a performance of a plurality of corrections. This occurs in particular if abnormalities are present in the quality history for which correction options are to be identified by means of detailed analyzes.
  • the dynamic test By means of the dynamic test, the influence of the correction possibility on the code can be analyzed.
  • their implementation can be prioritized. For example, in the case where a policy violation is to ensure that this rule is adhered to in the source code, the dynamic test helps to focus or prioritize the corrections to the most frequently used source code locations.
  • the dynamic test can capture the actual impact of each violation on the software. This detection can be done mainly with regard to the size of the loaded source code in the main memory (footprint) and / or the reactivity of the software (time for the software to respond to an input).
  • Figure 1 is a schematic representation of an embodiment of a method according to the invention for the automated evaluation of the quality of a software source code
  • Figure 2 is a schematic representation of an embodiment of a device according to the invention for the automated evaluation of the quality of a software source code.
  • Fig. 1 shows schematically an embodiment of the method according to the invention for the automated evaluation of the quality of a software source code.
  • Starting points for carrying out the method are the source code to be evaluated and to be improved, which is represented in FIG. 1 by the method component with the reference numeral 1.
  • a process component 2 represents a set of evaluation rules and metrics that can be used to verify the source code.
  • the valuation rules are documented, ie the valuation rules store attributes that enable or support selection of valuation rules and metrics.
  • the process component 2 further represents a predetermined quality goal indicating a desired quality that the software should have.
  • the quality objective is based on a given quality model, to which a multitude of quality characteristics is assigned.
  • the quality characteristics can be checked and evaluated by means of the evaluation rules and metrics. be judged. This also means that errors or sources of problems in the source code that do not meet the quality characteristics in the source code can be detected by means of the evaluation rules and metrics.
  • One of the quality features for example, the maintainability of the
  • the maintainability corresponds to an extent in which the software, i. H. the source code, can be changed. These changes include fixes as well as enhancements and adjustments to changes in the environment, requirements, and / or functional specification.
  • the maintainability can by other criteria, such. Simplicity or readability, will be further described.
  • the simplicity can be described, for example, by a metric CBOR, "high coupling through type use”.
  • This metric CBOR examines the coupling of a class with other classes.
  • a class coupled with many other classes is inherently complex, i. H. hard to understand because at least some of the classes used must be understood in order to understand the class itself. Therefore, this CBOR per class metric counts the number of different types for attributes, local variables, and return values.
  • the process components 1 and 2 thus represent predetermined conditions for carrying out the method according to the invention.
  • the source code is checked in a method step 3 by means of an automatic source code checking and metric tool by means of a set of the predetermined evaluation rules and metrics.
  • the part of predetermined evaluation rules and metrics used for checking is selected beforehand, for example, by a developer of the software or an expert according to specific, in particular project-specific criteria, so that only a part of the predetermined evaluation rules and metrics is used.
  • individual quality assessments are set, which are based on checking the source code by means of the individual evaluation rules and / or metrics of the set used for checking.
  • the individual quality assessments are advantageously each represented by key figures.
  • a review and evaluation of the results of the verification method step 3 is performed. In particular, it checks which evaluation rules and / or metrics are necessary and valid depending on the programming language, the application domain and the quality objective. This check can be automated. Alternatively or additionally, checking by an expert is also advantageous.
  • a decision is made on the basis of method step 4 as to whether at least one predefined criterion is satisfied when evaluating the checking of the source code that has been carried out. In particular, such can be an achieved degree of automation and / or achieved coverage of the source code during checking. If the at least one criterion is not fulfilled, then the method according to the invention branches to a method step 6. In this method step 6, the set of evaluation rules and / or metrics is adapted.
  • the method according to the invention then branches again to method step 3, in which the source code is checked by means of the adapted set of evaluation rules and metrics and of the automatic source code checking and metric tool.
  • the loop given by method steps 3, 4, 5, 6 and 8 is run through until it is determined in method step 5 that the at least one predefined criterion is fulfilled.
  • the method branches from method step 5 to method step 9, in which the results of the check carried out in method step 3 are summarized on the basis of the underlying quality model.
  • a method step 10 new evaluation rules and metrics in the quality model can be added.
  • the rating of the rating rules and metrics can be adjusted according to the quality objective.
  • the summarization of the results in method step 9 takes place in such a way that an overall quality assessment of the quality of the source code is determined by suitably combining the individual quality evaluations generated in method step 3 for the individual evaluation rules and / or metrics.
  • a mapping function can be defined, with which the individual quality evaluations for the individual evaluation rules and / or metrics are linked to one another in a weighted manner.
  • the overall quality rating is also represented by a measure for the sake of simplicity.
  • the summary of the assessment for the overall quality assessment carried out in method step 9 can be checked by the expert, in particular on the basis of a plausibility check.
  • a final evaluation of this current version of the software is then available.
  • the automatically generated individual evaluations of the quality of the software are advantageously additionally secured by the expert examination, which ensures a high reliability of the evaluation.
  • the final score is added to a quality history in a step 13.
  • This quality history contains overall quality ratings of various versions of the source code.
  • the development of the software, and in particular the structure of its functionality, is done by version. This means that the different versions build on each other and usually a new version improves the functionality, performance and quality of a previous version. Since the summarized assessments of the different versions of the software are included in the quality history, it is possible to compare this sequence of quality scores. This takes place in method step 13.
  • evaluation rules or metrics added in the course of checking newer versions are applied to quality evaluations of older predecessor versions contained in the quality history. As a result, these predecessor versions are also examined by means of these new rules or metrics, so that further individual quality evaluations are created, which can additionally be used to assess certain trends in the development of the software.
  • correction options are identified in a procedural step 14 in case of abnormalities in the quality history. This is done by analyzing details of the software. For this purpose, additional dynamic tests can be performed during the operation of the software in order to determine the flow of certain corrections to the quality of the software. In the dynamic tests, the software is parameterized and the test system is created in order to be able to determine the concrete evaluation code for the corrected software. In method step 14, it is likewise possible to prioritize the execution of several correction options. When applying rules that take into account conflicting constraints, it is preferable to choose a procedure that ensures that changes made will converge towards the overall quality objective.
  • Controlling the quality of the software by identifying and testing the correction possibilities can be supported by means of an existing solution library. This is illustrated in FIG. 1 by method step 15.
  • identified correction options are then incorporated into the source code in order to improve and expand the software. In the case of a prioritization of the correction options, these are incorporated according to their priority.
  • method step 17 an improved new software version is then available. This is then forwarded to the automatic source code verification and metric tool previously described in step 3. The test of the new software version then takes place in the manner described above.
  • the device according to the invention here is a computer 20.
  • the computer 20 has a screen 21 and an input means, which here is a keyboard 22.
  • the computer 20 further includes a control device 23, which controls the operations of the computer 20 and in particular the execution of the inventive method.
  • the controller 23 includes a processor and a memory in which a suitable program, i. H. a software is stored that can be executed by the processor to perform the inventive method.
  • the control device 23 contains a software memory 24, in which the source code of the software is stored, whose quality is to be evaluated. The controller 23 thus accesses the memory 24 during the evaluation and checking of the source code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft ein Verfahren und eine Vorrichtung (1) zum automatisierten Bewerten der Qualität eines Software-Quellcodes (10), bei dem Bewertungsregeln und/oder Metriken zum Beurteilen der Qualität des Quellcodes (1) vorgegeben sind (2). Dabei wird der Quellcodes (1) mittels eines Satzes von Bewertungsregeln und/oder Metriken überprüft (3), wobei der Satz wenigstens einen Teil der vorgegebenen Bewertungsregeln und/oder Metriken aufweist. Weiterhin wird der zum Überprüfen des Quellcodes (1) eingesetzte Satz von Bewertungsregeln und/oder Metriken in Abhängigkeit von einem Bewerten (4, 5) des durchgeführten Überprüf ens des Quellcodes (D hinsichtlich wenigstens eines vorgegebenen Kriteriums angepasst (6), um einen angepassten Satz von Bewertungsregeln und/oder Metriken zu bilden (8), der von dem Satz verschieden ist. Des Weiteren wird der Quellcode (1) mittels des angepassten Satzes von Bewertungsregeln und/oder Metriken überprüft (3).

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 .

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.
PCT/EP2006/064844 2005-09-05 2006-07-31 Verfahren und vorrichtung zum automatisierten bewerten der qualität eines software-quellcodes WO2007028676A2 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP06792612A EP1922613A2 (de) 2005-09-05 2006-07-31 Verfahren und vorrichtung zum automatisierten bewerten der qualität eines software-quellcodes
US11/991,429 US20090055804A1 (en) 2005-09-05 2006-07-31 Method and device for automatically evaluating the quality of a software source code

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005042126A DE102005042126A1 (de) 2005-09-05 2005-09-05 Verfahren und Vorrichtung zum automatisierten Bewerten der Qualität eines Software-Quellcodes
DE102005042126.1 2005-09-05

Publications (2)

Publication Number Publication Date
WO2007028676A2 true WO2007028676A2 (de) 2007-03-15
WO2007028676A3 WO2007028676A3 (de) 2007-11-08

Family

ID=37719334

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/064844 WO2007028676A2 (de) 2005-09-05 2006-07-31 Verfahren und vorrichtung zum automatisierten bewerten der qualität eines software-quellcodes

Country Status (4)

Country Link
US (1) US20090055804A1 (de)
EP (1) EP1922613A2 (de)
DE (1) DE102005042126A1 (de)
WO (1) WO2007028676A2 (de)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10402757B1 (en) * 2007-03-16 2019-09-03 Devfactory Fz-Llc System and method for outsourcing projects
US8627287B2 (en) * 2007-11-29 2014-01-07 Microsoft Corporation Prioritizing quality improvements to source code
US8875118B1 (en) * 2008-05-14 2014-10-28 Bank Of America Corporation Application configuration managment
US20100070949A1 (en) * 2008-09-15 2010-03-18 Infosys Technologies Limited Process and system for assessing modularity of an object-oriented program
CA2734199C (en) * 2010-03-18 2017-01-03 Accenture Global Services Limited Evaluating and enforcing software design quality
US20110321007A1 (en) * 2010-06-29 2011-12-29 International Business Machines Corporation Targeting code sections for correcting computer program product defects using records of a defect tracking system
US8701198B2 (en) * 2010-08-10 2014-04-15 Salesforce.Com, Inc. Performing security analysis on a software application
US9507940B2 (en) 2010-08-10 2016-11-29 Salesforce.Com, Inc. Adapting a security tool for performing security analysis on a software application
DE102011006215A1 (de) * 2010-11-09 2012-05-10 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Ermitteln einer Qualitätsbewertung eines Softwarecodes mit Ermittlung der Bewertungsabdeckung
US8584079B2 (en) * 2010-12-16 2013-11-12 Sap Portals Israel Ltd Quality on submit process
US9286187B2 (en) * 2012-08-30 2016-03-15 Sap Se Static enforcement of process-level security and compliance specifications for cloud-based systems
US9286394B2 (en) 2013-07-17 2016-03-15 Bank Of America Corporation Determining a quality score for internal quality analysis
US9378477B2 (en) 2013-07-17 2016-06-28 Bank Of America Corporation Framework for internal quality analysis
US9813450B1 (en) 2015-02-16 2017-11-07 Amazon Technologies, Inc. Metadata-based verification of artifact quality policy compliance
US9619363B1 (en) * 2015-09-25 2017-04-11 International Business Machines Corporation Predicting software product quality
FR3042291B1 (fr) * 2015-10-09 2017-11-17 Centre Nat D'etudes Spatiales C N E S Dispositif et procede de verification d'un logiciel
US10268824B2 (en) 2016-03-01 2019-04-23 Wipro Limited Method and system for identifying test cases for penetration testing of an application
CN108121656A (zh) * 2016-11-30 2018-06-05 西门子公司 一种软件评估方法和装置
US11157844B2 (en) * 2018-06-27 2021-10-26 Software.co Technologies, Inc. Monitoring source code development processes for automatic task scheduling
US11138366B2 (en) 2019-02-25 2021-10-05 Allstate Insurance Company Systems and methods for automated code validation
CN111080834A (zh) * 2019-10-31 2020-04-28 北京航天自动控制研究所 一种利用索引对测发控软件巡检数据配置判据的方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7669180B2 (en) * 2004-06-18 2010-02-23 International Business Machines Corporation Method and apparatus for automated risk assessment in software projects

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Software engineering-Product quality - Part 2: External metrics", ISO/IEC TECHNICAL REPORT, 1 July 2003 (2003-07-01), pages 9126 - 2
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
RAMOS C. S. ET AL.: "Legacy Software Evaluation Model for Outsourced Maintainer", SOFTWARE MAINTENANCE AND REENGINEERING, 2004, pages 48 - 57
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
SCHNEIDEWIND ET AL.: "IEEE Standard for a Software Quality Metrics Methodology", IEEE STD, 12 March 1993 (1993-03-12), pages 1061 - 1992

Also Published As

Publication number Publication date
EP1922613A2 (de) 2008-05-21
US20090055804A1 (en) 2009-02-26
WO2007028676A3 (de) 2007-11-08
DE102005042126A1 (de) 2007-03-15

Similar Documents

Publication Publication Date Title
WO2007028676A2 (de) Verfahren und vorrichtung zum automatisierten bewerten der qualität eines software-quellcodes
DE69720821T2 (de) Fehlersuchsystem für Programme mit einer graphischen Benutzerschnittstelle
DE102006046203A1 (de) Verfahren zur rechnergestützten Bewertung von Softwarequellcode
DE102004024262A1 (de) Wissensbasiertes Diagnosesystem für ein komplexes technisches System mit zwei getrennten Wissensbasen zur Verarbeitung technischer Systemdaten und zur Verarbeitung von Kundenbeanstandungen
WO2008064658A2 (de) Verfahren zum testen eines computerprogramms
DE102011014830A1 (de) Verfahren und vorrichtung zum analysieren vonsoftware
EP3082000A1 (de) Verfahren und system zum testen eines mechatronischen systems
DE102014102551A1 (de) Maschine und Verfahren zum Evaluieren von fehlschlagenden Softwareprogrammen
WO2023041458A2 (de) Computerimplementierte verfahren, module und system zur anomalieerkennung in industriellen fertigungsprozessen
DE102010033861A1 (de) Auf einer formellen Analyse basierte Entwicklung von Anforderungsspezifikationen
DE102005042129A1 (de) Verfahren und Vorrichtung zum automatisierten Bewerten der Qualität eines Software-Quellcodes
DE112009000211T5 (de) Programmprüfvorrichtung und -programm
DE102011014831A1 (de) Verfahren und vorrichtung zum analysieren vonsoftware mit einem kalibrierten wert
EP3232327B1 (de) Verfahren zum testen eines steuerprogramms eines steuergeräts in einer simulationsumgebung auf einem rechner
EP3306295A1 (de) Verfahren und vorrichtung zum testen elektronischer steuerungen, insbesondere zum testen von automobilsteuerungen
DE102009004531B4 (de) Verfahren zum Verifizieren eines Fertigungsprozesses
DE102020206327A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102019219067A1 (de) Verfahren zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE102022201856A1 (de) Automatisches generieren eines fuzzing-plans für das fuzzing eines programmiercodes
EP1237118B1 (de) Verfahren zum Spezifizieren, Ausführen und Analysieren von Verfahrensabläufen beim Erkennen
DE102020215387A1 (de) Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE102020205526A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102010014720A1 (de) Verfahren zum Verifizieren eines aus einem Quellmodell generierten Zielprogramms
DE102020211519A1 (de) Bewertung von warnmeldungen in der statischen code-analyse
Pasquini et al. Human performance reliability in the design-for-usability life cycle for safety human-computer interfaces

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
REEP Request for entry into the european phase

Ref document number: 2006792612

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006792612

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11991429

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2006792612

Country of ref document: EP