EP2069920A1 - Method for the computer-assisted analysis of a software source code - Google Patents

Method for the computer-assisted analysis of a software source code

Info

Publication number
EP2069920A1
EP2069920A1 EP07820578A EP07820578A EP2069920A1 EP 2069920 A1 EP2069920 A1 EP 2069920A1 EP 07820578 A EP07820578 A EP 07820578A EP 07820578 A EP07820578 A EP 07820578A EP 2069920 A1 EP2069920 A1 EP 2069920A1
Authority
EP
European Patent Office
Prior art keywords
error
source code
quality
errors
software source
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
EP07820578A
Other languages
German (de)
French (fr)
Inventor
Christian Körner
Anja Hentschel
Reinhold PLÖSCH
Stefan Schiffer
Stephan Storck
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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 AG filed Critical Siemens AG
Publication of EP2069920A1 publication Critical patent/EP2069920A1/en
Ceased legal-status Critical Current

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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management

Definitions

  • the invention relates to a method and a device for the computer-aided evaluation of software source code and a corresponding computer program product.
  • the invention is concerned with improving the code quality of software systems. There are many basic difficulties in improving software code quality. Often, there is no way to perform correctness proofs for software from non-trivial large systems. In addition, the large amount prepares
  • Source code which usually grow strongly during the lifetime of a software system, difficulties in analyzing the co ⁇ of.
  • problem areas ie of potentially faulty points.
  • experts available for evaluating, assigning and solving manually or automatically identified problem areas in the software source code.
  • Another problem arises from the fact that software solutions today usually have to be created and updated in very short time cycles.
  • software systems must take into account a variety of explicit and implicit informal requirements as well as formal and informal constraints.
  • there are a number of changing technical implementation approaches in the development of software such as middleware, class libraries, different programming languages and runtime environments. The different implementations usually only focus on specific technical aspects, without considering other aspects, such as ensuring software quality.
  • Software source code is usually not technical. This relies primarily on the experience of experts who try to read through the software source code in a structured way. Individual experts or a team of experts identify, discuss and document potential sources of error. As a result, in addition to a list of identified errors and potential sources of error, there is usually a quality assessment in the form of a prose text. In some cases, this square is formality assessment completed by a list of always behindi ⁇ sen and recommendations.
  • the object of the invention is therefore to provide a method and a device for the computer-aided evaluation of software to provide source code, with which a simple way a structured categorization of the errors in the software source code is created in order then to be able to improve the software source code based on the categorization quickly.
  • Software source code comprising initially taking account of parame ⁇ tern coding rules and / or coding metrics analyzed, being determined as an analysis result in the software source code detected error.
  • An encoding rule is a clearly defined rule which, if not fulfilled, violates the rule.
  • a Codie ⁇ metric approximately a determinable from the software source code or the executable program size which agreed an indicator of be ⁇ , errors contained in the software.
  • An example of a coding metric is the number of lines of code in a software source code. Coding metrics are particularly well known on the technical constraints of the computer systems used as storage capacity, response times, throughput, restart possibilities after stopping the sequence, opportunities, updates, etc.
  • each error class is assigned a a Be ⁇ user interface dispensable specification wel ⁇ che describes the errors of the respective error class.
  • those error classes to which detected errors are assigned are output via a user station.
  • each error class is associated with one of the following per ⁇ programming technical categories: one category relating notation conventions; a category regarding type declarations and / or definitions; a category regarding program instructions; a category regarding memory problems; a category regarding software protocols; a category relating to the design and / or architecture of the software source code; A category relating to the time response for the off ⁇ management of the software source code.
  • the error classes are assigned to the programming-technical categories via the detection mechanism, with which errors of an error class are identified. In this way, a clear and unambiguous programming criterion is created, via which an assignment of errors to error classes takes place.
  • the specification of the respective error class comprises one or more, in particular all, of the following descriptions: A description of a development goal which is to be achieved by the correction of the errors of the corresponding error class.
  • the purpose of the development is to make it clear why it makes sense to do so avoid problems subsumed under this error class.
  • a description of the detection mechanism which indicates ⁇ how errors in the respective error class detek- advantage. It describes how to identify the problem described by the error class.
  • general detection techniques are listed in a general error class, while for a concrete error class the exact rules for the existence of the violation of a coding rule or for the calculation of values an encoding metric are given.
  • the individual error classes can be sorted again according to their degree of abstraction.
  • the Feh ⁇ lertren can be classified according to a hierarchical taxonomy in general, special and concrete error classes.
  • the taxa may be chosen and arranged according to the 7 + -2 rules known in the art (see George A. Miller: The Magical Number Series, Plus or Minus Two; The Psychological Review, 1956, Vol. 63, pages 81 to 97). In this way are different Created hierarchical levels of error classes, which in deeper hierarchical levels, the error classes are becoming more specific and concrete.
  • the general error classes summarize in some way the goals of each quality improvement process, namely the avoidance of precisely those errors which are finally attributable to this general error class. They specify the direction or meaning and purpose for the troubleshooting or for the quality improvement.
  • specific error clauses preferably summarize a lot of similar coding errors. They limit the reasons and the possible solutions.
  • a hierarchical structuring of the problem Klas ⁇ sen is possible.
  • This results in a logical structure of the concrete error classes is achieved, and the possibility created friendliness beyond to specify a solution ⁇ direction to remedy the problems associated therewith for individual error classes.
  • specific error classes are preferably assigned directly assigned coding rules and metrics which describe localized errors or limit value overflows of metrics.
  • the errors in the concrete error classes are in particular assigned automatable solutions for the elimination of the problems.
  • the hierarchical structuring of the error classes can be used to start from an identified one
  • an evaluation of the detected errors is made. ler performed, will be ⁇ for each issued error class egg ⁇ ne quality assessment of the error class on the basis of the error contained therein relating to a user interface out.
  • the user immediately receives a feedback on how difficult the errors contained in the software source code in the individual error classes are.
  • an overall evaluation of the quality of the software source code on the basis of the quality evaluations of the error classes is determined and output via a user interface. In this way, a user immediately gets an overview of how to rank the overall quality of the software source code.
  • the quality Bewer ⁇ obligations of the error classes and / or the overall quality assessment is based in this case preferably to predetermined numerical values.
  • the overall quality assessment can be determined in particular in a simple manner by summing up the measures of the quality assessments of the error classes.
  • the method is configured such that a Benut ⁇ cut constitutes a target quality of the software source code can be entered, wherein the target quality is compared with the actual quality in accordance with the quality of the error classes and / or the overall quality and the corresponding comparison result is issued via a user interface ⁇ .
  • certain desirable quality requirements can be set automatically by a user, the method automates these quality requirements into consideration, and outputs, if these dismisssanfor ⁇ requirements will be met by the software source code.
  • the quality assessments of the error classes and / or the overall quality evaluation are stored in a retrievable memory, whereby a quality history of different versions of software source codes is stored in the memory.
  • a quality history of different versions of software source codes is stored in the memory.
  • the genetic ⁇ tured quality history and the respective actual and desired qualities qualities of the versions of the software source code are stored.
  • change requests for the software source code are generated from the quality evaluations of the error classes, and change messages are created from the change requests, wherein the changes in a change message are respectively assigned to a person or group of persons who are responsible for the change Implementation of the changes in the change notification.
  • criteria may moreover be entered via a user interface, these criteria being taken into account when generating the change requests.
  • Such criteria include customized quality reviews, that it was manually calculated by experts that the quality due to external To ⁇ stands must be assessed somewhat differently than it automates the process of this invention is carried out is.
  • the change messages are each automatically transmitted to the person or group of people responsible for making the changes in the change notification.
  • the responsible person can be sent the change notification automatically via e-mail as a file.
  • the change messages can also contain instructions for carrying out the change and / or an estimate of the effort of the changes. It can be a berisoni ⁇ ge metric for determining expense used herein, game instance that are needed at ⁇ a cost metric, which as a result indicates the man ⁇ hours to perform the change.
  • the instructions for carrying out the changes also contain a sample solution for changing the software source code, wherein the pattern solutions are preferably each assigned an expense for carrying out the sample solution.
  • the error classes include quality error classes which categorize the errors according to quality criteria.
  • the coding error can be subordinate to a quality model to ⁇ , which is independent of a purely technical classification view is created on the coding error.
  • the invention further relates to a device for computer-aided evaluation of software source code, comprising: an analysis means for analyzing the software source code taking into account parameters including coding rules and / or coding metrics, wherein errors detected by the analysis means as an analysis result in the software source code become; a classification means for classifying the defect detected by the defect detected respectively At the very least be associated with fault classes of a class of a plurality, each fault class conces- an egg over ⁇ ne user interface specification outputtable is ordered which describes the errors of the respective error class; an output means for outputting those error classes to which detected errors are associated via a user interface.
  • the invention further relates to a computer program product having a program code stored on a machine-readable carrier for carrying out the inventive method described above when the program is run on a computer.
  • FIG. 1 is a schematic illustration in which the inventive method is used a Softwareent ⁇ development process
  • FIG. 2 shows an embodiment of a device according to the invention for the computer-aided evaluation of software source code.
  • the sources of software programs should be as legible as possible to be understandable and maintainable.
  • the notation of sources as text plays an essential role here.
  • the notations concern names for symbols and artifacts, the style and the documentation.
  • the syntax does not specify in which form (indents, brackets, line breaks, comment formats, etc.) programs must be written.
  • stylistic rules and nuances in which context which language constructs should be used and how they are used, regardless of whether alternative formulations are possible due to the syntax of the programming language.
  • Design goal in terms of style is to use the programming language from a stylistic point of view that the established in the industry and perceived as good quality stylistic rules are met.
  • Names or identifiers in the program code are either ambiguous or do not allow any conclusion to the underlying phenomenon of the application domain.
  • Missing or linguistically inconsistent requirement specifications do not define a clear vocabulary that could be used for naming. Therefore, the developers use fictitious identifiers that are neither defined nor unique.
  • Compliance with programming guidelines ie compliance with stylistic specifications, can usually be ensured automatically by means of static code analysis tools.
  • Compliance with naming conventions can - for general naming conventions - also be carried out using appropriate static code analysis tools.
  • the semantically correct The use of names in the context of the domain under consideration can only be ensured manually by appropriate reviews.
  • the source code looks messy and crafty bad. Ambiguous identifiers cause communication problems. This has a direct impact on the maintainability of the code.
  • all identifiers are associated with the type name that best fits the usage context of the identifier. In this sense, the type name is then well chosen if no Verwen ⁇ tion errors of the identifier can occur or even no explicit type conversions are required.
  • identifiers should be chosen so that only those types that are actually needed are visible to the outside world.
  • a development goal violation exists when using types that are not meaningful in the context of using identifiers.
  • Injury to the development target also exists if the declaration of an identifier is performed so that the user of an identifier can be known (for example the parameters of a method) due to the used type implementation details that should not be known from sachli ⁇ cher view.
  • Defects regarding type declarations and definitions are determined from the rule set of the code analyzers or derived control metrics, such as the number of type conversions, the number of type violations, and so on.
  • type conversion operators can lead to a loss of computational accuracy or even crashes, depending on the type conversion.
  • the coding errors of this error class depend on the type of instruction. Contains either the instruction semantically incorrect ingredients or the instruction is at least semantically questionable unnecessary to complex or incomplete ⁇ constantly.
  • Instruction errors are detected from the rule set of the code analyzers and control metrics derived therefrom, e.g. from the number of dubious, redundant and unattainable statements.
  • a violation of the development goal (s) - depending on the nature of the violation - can have a negative impact on the correctness of the program.
  • the correction of memory problems may be made by the developer himself, possibly after training.
  • Memory problems can be determined from the rule set of the code analyzers and control metrics derived therefrom, e.g. from the number of dubious or false statements that change the state of the memory.
  • Implicit protocols are not sufficiently known or documented.
  • Implicit protocols should of course documented ⁇ to. Developers should be trained on the protocols used.
  • Detection of violation of software protocols can be done by manual reviews, the analysis of call trees with data flow analysis or the used machines.
  • the logs can also be checked automatically using static and dynamic code analysis tools.
  • the result is a software system in an inconsistent or unstable state.
  • the primary design goal is to make the architecture and De ⁇ sign of a system so that so that made on this system functional and non-functional require- and expected changes and extensions of the requirements in the design or in the architecture are anticipated.
  • the architecture and design have general technical software quality requirements fulfillment ⁇ len. These requirements are in particular:
  • the determination of errors in design or architecture can be done manually or by an analysis tool (e.g., Sotograph),
  • a correction of comprehension errors can be done by appropriate training of the developers. Coding errors can be corrected by the developer himself.
  • a violation of the development goal occurs when the system has inadequate synchronization mechanisms.
  • the observable consequences are blockages, sequencing problems, pointless operations, inefficient algorithms, inadequate response times, and poor throughput.
  • the software system was designed, developed and tested only for a processing context.
  • the developers of the system have no experience with concurrent systems, ie systems with several simultaneously processed processing contexts .
  • Correction can be done by staff training, software code re-design or code correction.
  • Errors in the time behavior can be detected by data flow analysis via call graphs or by checking coding rules.
  • error classes may possibly occur, for example are summarized in an "Other" category.
  • domain or project-specific error ⁇ classes are technology- collected.
  • Fig. 1 shows a flow diagram of a Software reliespro ⁇ zesses, in which an embodiment of the inventive method is embedded.
  • the software system is in the form of a software source code SQ.
  • the software source code is analyzed on the basis of coding rules or metrics, which is indicated by step 1.
  • coding rules or metrics which is indicated by step 1.
  • known static code analysis tools or other methods may be used, such as standard test procedures.
  • the test procedures and their parameters can come, for example, from the last iteration of the project, ie the last software version.
  • the coding rules or metrics are adapted in accordance with predefined requirements.
  • step 4 an agreement or adaptation of quality objectives with the responsible persons (subproject leader or their quality assurance officers) takes place.
  • the quality goals to be achieved are agreed or already set quality targets are adjusted.
  • step 5 the actual quality of the software source code is compared with the target quality.
  • step 6 an analysis result is then output, which contains the comparison of target quality and actual quality for the present software source code version.
  • This analysis is stored in Step 7 in a memory, in which the quality history is deposited by reciprocating before ⁇ software source code versions.
  • step 8 a manual check of the
  • step 9 is carried out the automatic generation of the change requests and the automatic generation of notifications of changes to the corresponding controller, possibly with a solution of a note and cost ⁇ estimate.
  • Solution notes in particular sample solutions, are taken from a solution database LB.
  • steps 10 to 12 are standard steps of a software creation process.
  • steps 2 to 9 set forth above is essentially based on the error classification developed according to the invention. In particular, allows floristklassifikati ⁇ on:
  • targets on a general abstract plane ben by the classification accordingly and this which is adapted to be understood by Project ⁇ heads or quality manager.
  • the method according ⁇ invention is an automated improving the quality of a software source code by way of a targeted loading of errors contained in the software source code.
  • Different error classes are predefined, and these error classes are assigned detection mechanisms for detecting the errors.
  • the software source code is checked by the detection mechanisms, and detected errors are assigned to an error class.
  • According to different types of the software source code ent ⁇ preserved errors can be detected and treated systematically and efficiently.
  • the procedure reduces the increased degree of automation and the focus down to the kriti ⁇ rule technical aspects of the effort to control the software code quality considerably. It forms a bridge from the error detection methods of classical code analysis to targeted improvement measures, which increase the code quality efficiently.
  • Fig. 2 shows an embodiment of a device with which the inventive method can be realized.
  • the device comprises user interfaces, which are combined in a presentation layer PL.
  • Examples of such user interfaces that display the results of the method according to the invention are laptops LP, a workstation WS and a printer P.
  • the user interfaces interact with different modules, which are combined to form an application layer AL.
  • a module M1 is provided which represents a report generator.
  • this module provides the change messages created according to the invention.
  • an interaction module M2 is provided, which represents the interface to the presentation layer PL.
  • the actual method according to the invention, ie the classification of the errors takes place in module M3, which represents an evaluator.
  • Module M5 compares the determined target quality with the actual quality.
  • a Statistical tikmodul is provided M7, which statistical analysis carried out be ⁇ fab of errors found.
  • a data interface is provided as module M6, which interfaces with the data layer explained below DL represents.
  • it is provided as a central module M4 in the application layer AL, a control unit, wel ⁇ che controls the interaction between the other modules.
  • the data layer DL contains the data processed or generated in the method according to the invention.
  • three data sets D1, D2 and D3 are indicated.
  • a ⁇ Me Thode administration is provided as a data record D2 that manages the methods of classification and error detection.
  • This dataset is organization-specific but cross-project.
  • the quality history D3 of bre ⁇ heren software versions is included in the data layer DL.
  • the quality history D3 is cross-organizational and cross-project.

Abstract

The invention relates to a method for the computer-assisted analysis of a software source code (SQ). According to the method, the software source code (SQ) is analyzed in consideration of parameters comprising encoding rules and/or encoding metrics, wherein as the analysis result errors (ER) detected in the software source code (SQ) are calculated. The errors (ER) detected are classified by means of associating them with at least one error category (EC) from a plurality of error categories (EC). To this end, a specification that can be output via a user interface is associated with each error category (EC), which describes the errors (ER) of the respective error category (EC). The error categories (EC) with which the detected errors (ER) are associated are then output via a user interface. According to the invention, different types of errors contained in the software source code can be systematically and efficiently detected and handled. The method significantly reduces the efforts of controlling the software code quality, due to the increased degree of automation and the ability to focus on the critical technical aspects. Thus, it builds a bridge from the error detection methods of conventional code analysis to targeted measures of improvements, which are able to efficiently increase code quality.

Description

Beschreibungdescription
Verfahren zur rechnergestützten Bewertung von SoftwarequellcodeMethod for the computer-aided evaluation of software source code
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur rechnergestützten Bewertung von Softwarequellcode und ein entsprechendes Computerprogrammprodukt .The invention relates to a method and a device for the computer-aided evaluation of software source code and a corresponding computer program product.
Die Erfindung beschäftigt sich mit der Verbesserung der Codequalität von Softwaresystemen. Bei der Verbesserung von Softwarecodequalität gibt es eine Vielzahl von grundlegenden Schwierigkeiten. Oft gibt es keine Möglichkeiten, Korrektheitsbeweise für Software von nicht-trivialen großen Systemen durchzuführen. Darüber hinaus bereitet die große Menge anThe invention is concerned with improving the code quality of software systems. There are many basic difficulties in improving software code quality. Often, there is no way to perform correctness proofs for software from non-trivial large systems. In addition, the large amount prepares
Quellcode, der während der Lebenszeit eines Softwaresystems meist stark wächst, Schwierigkeiten bei der Analyse des Co¬ des. Ferner gibt es in großen Softwaresystemen eine Vielzahl von Problemstellen, d.h. von potentiell fehlerbehafteten Stellen. Oftmals stehen auch nicht genügend Experten für die Bewertung, Zuordnung und Lösung von manuell oder automatisiert ermittelten Problemstellen im Softwarequellcode zur Verfügung. Ein weiteres Problem ergibt sich daraus, dass Softwarelösungen heutzutage meistens in sehr kurzen Zeitzyk- len erstellt und aktualisiert werden müssen. Darüber hinaus ist bei Softwaresystemen eine Vielzahl von expliziten und impliziten informellen Anforderungen sowie von formellen und informellen Randbedingungen zu berücksichtigen. Darüber hinaus ist zu berücksichtigen, dass es bei der Entwicklung von Software eine Vielzahl von wechselnden technischen Realisierungsansätzen gibt, wie z.B. Middleware, Klassenbibliotheken, unterschiedliche Programmiersprachen und Laufzeitumgebungen. Die unterschiedlichen Realisierungen konzentrieren sich dabei meist nur auf bestimmte technische Aspekte, ohne andere As- pekte, wie z.B. die Sicherstellung der Softwarequalität, in Betracht zu ziehen. Die heutzutage mit statischen Codeanalyseverfahren ermittelten Codierungsfehlermeldungen sind in der Regel weitgehend unstrukturiert und aufgrund der großen Menge der Fehlermel¬ dungen schwer zu verarbeiten. Oftmals werden deshalb Codie- rungsfehler, die an sich bekannt sind, über viele Entwicklungszyklen hinweg nicht korrigiert. Ebenso tritt oft der Fall auf, dass Codierungsfehler falsch bzw. mit unzureichender Qualität ausgebessert werden.Source code, which usually grow strongly during the lifetime of a software system, difficulties in analyzing the co ¬ of. There are also in large software systems a variety of problem areas, ie of potentially faulty points. Often, there are not enough experts available for evaluating, assigning and solving manually or automatically identified problem areas in the software source code. Another problem arises from the fact that software solutions today usually have to be created and updated in very short time cycles. In addition, software systems must take into account a variety of explicit and implicit informal requirements as well as formal and informal constraints. In addition, it should be noted that there are a number of changing technical implementation approaches in the development of software, such as middleware, class libraries, different programming languages and runtime environments. The different implementations usually only focus on specific technical aspects, without considering other aspects, such as ensuring software quality. The coding error messages nowadays determined with static code analysis methods are largely unstructured in general and difficult to process due to the large amount of error indication ¬ applications. Often coding errors, which are known per se, are therefore not corrected over many development cycles. Also, there is often the case that coding errors are corrected incorrectly or with inadequate quality.
Heutige Lösungsansätze zur Verbesserung der Qualität vonToday's solutions to improve the quality of
Softwarequellcode sind meist nicht technisch. Man verlässt sich hierbei primär auf die Erfahrung von Experten, welche versuchen, den Softwarequellcode in strukturierter Weise vollständig durchzulesen. Dabei werden von einzelnen Experten oder in einem Expertenteam potentielle Fehlerquellen identifiziert, erörtert und dokumentiert. Als Gesamtergebnis liegt dann meist neben einer Liste der identifizierten Fehler und potentiellen Fehlerquellen eine Qualitätseinschätzung in der Form eines Prosatextes vor. In manchen Fällen wird diese Qua- litätseinschätzung durch eine Liste von Verbesserungshinwei¬ sen und Empfehlungen ergänzt.Software source code is usually not technical. This relies primarily on the experience of experts who try to read through the software source code in a structured way. Individual experts or a team of experts identify, discuss and document potential sources of error. As a result, in addition to a list of identified errors and potential sources of error, there is usually a quality assessment in the form of a prose text. In some cases, this square is formality assessment completed by a list of Verbesserungshinwei ¬ sen and recommendations.
Aus dem Stand der Technik sind Ansätze bekannt, bei denen die Fehlermeldungen von Codeanalyseverfahren zusammengefasst wer- den. Diese Zusammenfassung ist meist sehr willkürlich. Beispielsweise sind die Fehlermeldungen des C++-Analyse- Werkzeugs PC-Lint nur rudimentär nach dem möglichen Ausmaß der sich daraus ergebenden Probleme gegliedert. Darüber hinaus sind Ansätze bekannt, bei denen Fehler im Softwarequell- code in technische Bereiche gegliedert werden. Bei den be¬ kannten Lösungsansätzen ist es nachteilhaft, dass nach der Analyse des Softwarequellcodes einem Benutzer keine einfache Struktur vorgegeben wird, aus der entnommen werden kann, welche Kriterien durch die einzelnen Programmierfehler nicht er- füllt werden.Approaches are known from the prior art in which the error messages are summarized by code analysis methods. This summary is usually very arbitrary. For example, the error messages of the C ++ analysis tool PC-Lint are only rudimentarily subdivided according to the possible extent of the resulting problems. In addition, approaches are known in which errors in the software source code are subdivided into technical areas. In the be ¬ known solutions, it is disadvantageous that after analyzing the software source code, a user is given no simple structure, can be removed from the criteria which are not filled replaced by the individual programming errors.
Aufgabe der Erfindung ist es deshalb, ein Verfahren und eine Vorrichtung zur rechnergestützten Bewertung von Software- quellcode zu schaffen, mit denen auf einfache Weise eine strukturierte Kategorisierung der Fehler im Softwarequellcode geschaffen wird, um anschließend auf der Basis der Kategorisierung den Softwarequellcode schnell verbessern zu können.The object of the invention is therefore to provide a method and a device for the computer-aided evaluation of software to provide source code, with which a simple way a structured categorization of the errors in the software source code is created in order then to be able to improve the software source code based on the categorization quickly.
Diese Aufgabe wird durch die unabhängigen Patentansprüche ge¬ löst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.This object is achieved by the independent claims ge ¬ triggers. Further developments of the invention are defined in the dependent claims.
Gemäß dem Verfahren der Erfindung wird der zu bewertendeAccording to the method of the invention, the one to be evaluated
Softwarequellcode zunächst unter Berücksichtigung von Parame¬ tern umfassend Codierungsregeln und/oder Codierungsmetriken analysiert, wobei als Analyseergebnis im Softwarequellcode detektierte Fehler ermittelt werden. Eine Codierungsregel ist dabei eine eindeutig festgelegte Vorschrift, bei deren Nicht- erfüllen die Regel verletzt ist. Demgegenüber ist eine Codie¬ rungsmetrik eine aus dem Softwarequellcode oder dem lauffähigen Programm bestimmbare Größe, welche ein Indikator für be¬ stimmte, in der Software enthaltene Fehler ist. Ein Beispiel einer Codierungsmetrik ist die Anzahl der Codezeilen in einem Softwarequellcode. Codierungsmetriken sind insbesondere ab¬ hängig von den technischen Randbedingungen der verwendeten Computersysteme, wie Speicherkapazitäten, Reaktionszeiten, Durchsätzen, Wiederanlauf-Möglichkeiten nach einem Stoppen des Ablaufes, Möglichkeiten, Updates einzuspielen, etc. Die detektierten Fehler werden anschließend klassifiziert, indem sie jeweils zumindest einer Fehlerklasse aus einer Mehrzahl von Fehlerklassen zugeordnet werden. Um eine einfache und klar strukturierte Einteilung in Fehlerklassen zu schaffen, ist gemäß der Erfindung jeder Fehlerklasse eine über eine Be¬ nutzerschnittstelle ausgebbare Spezifikation zugeordnet, wel¬ che die Fehler der jeweiligen Fehlerklasse beschreibt. Schließlich werden diejenigen Fehlerklassen, welchen detektierte Fehler zugeordnet sind, über eine Benutzerstelle aus- gegeben. Durch die Festlegung von Spezifikationen, insbesondere von technischen Spezifikationen, wird bei der Kategorisierung der Fehler klar festgelegt, welches erwünschte Ent¬ wicklungsziel nicht erreicht wird. Dem Benutzer des Verfah- rens wird somit durch die Ausgabe der Fehlerklassen struktu¬ riert mitgeteilt, welche spezifischen Anforderungen der Softwarequellcode nicht erfüllt, woraufhin entsprechende Gegen¬ maßnahmen ergriffen werden können.Software source code comprising initially taking account of parame ¬ tern coding rules and / or coding metrics analyzed, being determined as an analysis result in the software source code detected error. An encoding rule is a clearly defined rule which, if not fulfilled, violates the rule. In contrast, a Codie ¬ metric approximately a determinable from the software source code or the executable program size which agreed an indicator of be ¬, errors contained in the software. An example of a coding metric is the number of lines of code in a software source code. Coding metrics are particularly einzuspielen from ¬ pending on the technical constraints of the computer systems used as storage capacity, response times, throughput, restart possibilities after stopping the sequence, opportunities, updates, etc. The detected errors are then classified by at least one respective error class be assigned from a plurality of error classes. In order to provide a simple and clearly structured division into error classes, according to the invention, each error class is assigned a a Be ¬ user interface dispensable specification wel ¬ che describes the errors of the respective error class. Finally, those error classes to which detected errors are assigned are output via a user station. By establishing specifications, in particular technical specifications, is clearly defined in the categorization of the errors which desired Ent ¬ Development Goal will not be reached. The user of the procedure Rens is thus communicated struc ¬ riert by the output of the error classes, which does not meet specific requirements of the software source code, whereupon corresponding can be taken against ¬ measures.
Vorzugsweise wird jeder Fehlerklasse eine der folgenden pro¬ grammiertechnischen Kategorien zugeordnet: eine Kategorie betreffend Notations-Konventionen; eine Kategorie betreffend Typen-Deklarationen und/oder Definitionen; eine Kategorie betreffend Programm-Anweisungen; eine Kategorie betreffend Speicherprobleme; eine Kategorie betreffend Software-Protokolle; eine Kategorie betreffend das Design und/oder die Archi- tektur des Softwarequellcodes; eine Kategorie betreffend das Zeitverhalten bei der Aus¬ führung des Softwarequellcodes.Preferably, each error class is associated with one of the following per ¬ programming technical categories: one category relating notation conventions; a category regarding type declarations and / or definitions; a category regarding program instructions; a category regarding memory problems; a category regarding software protocols; a category relating to the design and / or architecture of the software source code; A category relating to the time response for the off ¬ management of the software source code.
Auf diese Weise werden die Fehler nach programmiertechnischen Kriterien kategorisiert . Es wird hierdurch schnell und intui¬ tiv einem Benutzer vermittelt, in welchen programmiertechnischen Bereichen vorgegebene Anforderungen nicht erfüllt sind.In this way, the errors are categorized according to programming criteria. It is hereby conveyed quickly and Dine on ¬ tive to a user in which technical programming areas specified requirements are not met.
In einer Ausführungsform der Erfindung werden die Fehlerklas- sen den programmiertechnischen Kategorien über den Detekti- onsmechanismus zugeordnet, mit dem Fehler einer Fehlerklasse identifiziert werden. Auf diese Weise wird ein klares und eindeutiges programmiertechnisches Kriterium geschaffen, über das eine Zuordnung von Fehler zu Fehlerklassen erfolgt.In one embodiment of the invention, the error classes are assigned to the programming-technical categories via the detection mechanism, with which errors of an error class are identified. In this way, a clear and unambiguous programming criterion is created, via which an assignment of errors to error classes takes place.
In einer besonders bevorzugten Ausführungsform der Erfindung umfasst die Spezifikation der jeweiligen Fehlerklasse eine oder mehrere, insbesondere alle, der folgenden Beschreibungen : - Eine Beschreibung eines Entwicklungsziels, welches durch die Behebung der Fehler der entsprechenden Fehlerklasse erreicht werden soll. Mit dem Entwicklungsziel soll klar gemacht werden, aus welchen Gründen es sinnvoll ist, die unter dieser Fehlerklasse subsumierten Probleme zu vermeiden .In a particularly preferred embodiment of the invention, the specification of the respective error class comprises one or more, in particular all, of the following descriptions: A description of a development goal which is to be achieved by the correction of the errors of the corresponding error class. The purpose of the development is to make it clear why it makes sense to do so avoid problems subsumed under this error class.
Eine Beschreibung der Verletzung des Entwicklungsziels, welche angibt, bei welchen Fehlern in der jeweiligen Feh- lerklasse das Entwicklungsziel nicht erreicht wird. In dieser Beschreibungskategorie wird explizit auf allgemei¬ ner Ebene beschrieben, unter welchen Umständen das Entwicklungsziel nicht erreicht wird. Eine Beschreibung der Ursachen für das Verfehlen des Ent- wicklungsziels. Hier werden typische Ursachen für dasA description of the breach of the development goal, which indicates for which errors in the respective error class the development goal is not reached. This description category explicitly describes at a general level the circumstances under which the development goal is not achieved. A description of the reasons for missing the development goal. Here are typical causes for that
Auftreten von Problemen in einer Fehlerklasse identifiziert und diskutiert.Occurrence of problems in an error class identified and discussed.
Eine Beschreibung der möglichen Korrekturen in Softwarequellcode, um das Entwicklungsziel zu erreichen. Hier wird festgelegt, durch welche Maßnahmen oder Techniken das Entwicklungsziel erreicht werden kann. Eine Beschreibung des Detektionsmechanismus, welche an¬ gibt, wie Fehler in der jeweiligen Fehlerklasse detek- tiert werden. Hier wird beschrieben, wie das durch die Fehlerklasse beschriebene Problem identifiziert wird. Im Falle, dass die Fehlerklassen ferner noch in allgemeine und spezifische Fehlerklassen eingeteilt sind, werden in einer allgemeinen Fehlerklasse allgemeine Detektionstech- niken aufgeführt, während bei einer konkreten Fehlerklas- se die genauen Vorschriften für das Vorliegen der Verletzung einer Codierungsregel bzw. zur Berechnung von Werten einer Codierungsmetrik angegeben sind.A description of the possible fixes in software source code to achieve the development goal. Here it is determined by which measures or techniques the development goal can be achieved. A description of the detection mechanism, which indicates ¬ how errors in the respective error class detek- advantage. It describes how to identify the problem described by the error class. In the case that the error classes are further divided into general and specific error classes, general detection techniques are listed in a general error class, while for a concrete error class the exact rules for the existence of the violation of a coding rule or for the calculation of values an encoding metric are given.
Die einzelnen Fehlerklassen können nochmals nach ihrem Abs- traktionsgrad sortiert werden. Insbesondere können die Feh¬ lerklassen gemäß einer hierarchischen Taxonomie in allgemeine, spezielle und konkrete Fehlerklassen eingeteilt werden. Zur Verbesserung der Übersicht, Wiedererkennung und Reproduzierbarkeit der Klassifikation können die Taxa nach den aus dem Stand der Technik bekannten 7+-2 Regeln gewählt und angeordnet werden (siehe George A. Miller: The Magical Number Se- ven, Plus or Minus Two; The Psychological Review, 1956, Vol. 63, Seiten 81 bis 97) . Auf diese Weise werden verschiedene Hierarchieebenen von Fehlerklassen geschaffen, wobei in tieferen Hierarchieebenen die Fehlerklassen immer spezieller und konkreter werden. Die allgemeinen Fehlerklassen fassen hierbei insbesondere die Ziele jedes Qualitätsverbesserungspro- zesses in irgendeiner Form zusammen, nämlich die Vermeidung gerade jener Fehler, die schließlich dieser allgemeinen Fehlerklasse zuordenbar sind. Sie geben die Richtung bzw. den Sinn und Zweck für die Fehlerbehebung bzw. für die Qualitätsverbesserung vor. Demgegenüber fassen spezifische Fehlerklas- sen vorzugsweise eine Menge ähnlicher Codierungsfehler zusammen. Sie grenzen die Gründe und die Lösungsmöglichkeiten ein. Damit ist eine hierarchische Strukturierung der Problemklas¬ sen möglich. Hierdurch wird eine logische Strukturierung der konkreten Fehlerklassen erreicht und darüber hinaus die Mög- lichkeit geschaffen, für einzelne Fehlerklassen eine Lösungs¬ richtung für die Behebung der damit assoziierten Probleme vorzugeben. Konkrete Fehlerklassen sind demgegenüber vorzugsweise direkt zugeordneten Codierungsregeln und Metriken zugewiesen, welche lokalisierte Fehler bzw. Grenzwertüberschrei- tungen von Metriken beschreiben. Den Fehlern in den konkreten Fehlerklassen sind insbesondere automatisierbare Lösungen für die Behebung der Probleme zugeordnet.The individual error classes can be sorted again according to their degree of abstraction. In particular, the Feh ¬ lerklassen can be classified according to a hierarchical taxonomy in general, special and concrete error classes. To improve the overview, recognition and reproducibility of the classification, the taxa may be chosen and arranged according to the 7 + -2 rules known in the art (see George A. Miller: The Magical Number Series, Plus or Minus Two; The Psychological Review, 1956, Vol. 63, pages 81 to 97). In this way are different Created hierarchical levels of error classes, which in deeper hierarchical levels, the error classes are becoming more specific and concrete. In particular, the general error classes summarize in some way the goals of each quality improvement process, namely the avoidance of precisely those errors which are finally attributable to this general error class. They specify the direction or meaning and purpose for the troubleshooting or for the quality improvement. On the other hand, specific error clauses preferably summarize a lot of similar coding errors. They limit the reasons and the possible solutions. Thus a hierarchical structuring of the problem Klas ¬ sen is possible. This results in a logical structure of the concrete error classes is achieved, and the possibility created friendliness beyond to specify a solution ¬ direction to remedy the problems associated therewith for individual error classes. By contrast, specific error classes are preferably assigned directly assigned coding rules and metrics which describe localized errors or limit value overflows of metrics. The errors in the concrete error classes are in particular assigned automatable solutions for the elimination of the problems.
Die hierarchische Strukturierung der Fehlerklassen kann dazu verwendet werden, um ausgehend von einem identifiziertenThe hierarchical structuring of the error classes can be used to start from an identified one
Problem, d.h. einer allgemeinen Fehlerklasse, auf systematische Weise zu überprüfen, wodurch das Problem verursacht wird. Diese Prüfung könnte dann systematisch durch Prüfung der entsprechenden spezifischen und konkreten Fehlerklassen erfolgen.Problem, i. a common error class, systematically reviewing what is causing the problem. This review could then be done systematically by examining the specific and specific error classes.
In einer weiteren Ausführungsform der Erfindung besteht ferner die Möglichkeit, detektierte Fehler nach vorgegebenen Kriterien zu filtern, so dass die angezeigten Fehlerklassen auf bestimmte interessierende Fehler eingeschränkt werden.In a further embodiment of the invention, it is also possible to filter detected errors according to predetermined criteria so that the displayed error classes are restricted to certain errors of interest.
In einer besonders bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens wird eine Bewertung der detektierten Feh- ler durchgeführt, wobei für jede ausgegebene Fehlerklasse ei¬ ne Qualitätsbewertung der Fehlerklasse auf der Basis der darin enthaltenen Fehler über eine Benutzerschnittstelle ausge¬ geben wird. Somit bekommt der Benutzer sofort eine Rückmel- düng dahingehend, wie schwer die im Softwarequellcode in den einzelnen Fehlerklassen enthaltenen Fehler sind. Vorzugsweise wird in dem erfindungsgemäßen Verfahren ferner eine Gesamtbewertung der Qualität des Softwarequellcodes auf der Basis der Qualitätsbewertungen der Fehlerklassen ermittelt und über ei- ne Benutzerschnittstelle ausgegeben. Auf diese Weise erhält ein Benutzer sofort einen Überblick, wie die Gesamtqualität des Softwarequellcodes einzustufen ist. Die Qualitätsbewer¬ tungen der Fehlerklassen und/oder die Gesamtqualitätsbewertung beruht hierbei vorzugsweise auf vorgegebenen Maßzahlen. Mit solchen Maßzahlen kann insbesondere auf einfache Weise die Gesamtqualitätsbewertung dadurch ermittelt werden, dass die Maßzahlen der Qualitätsbewertungen der Fehlerklassen aufsummiert werden.In a particularly preferred embodiment of the method according to the invention, an evaluation of the detected errors is made. ler performed, will be ¬ for each issued error class egg ¬ ne quality assessment of the error class on the basis of the error contained therein relating to a user interface out. Thus, the user immediately receives a feedback on how difficult the errors contained in the software source code in the individual error classes are. Preferably, in the method according to the invention, furthermore, an overall evaluation of the quality of the software source code on the basis of the quality evaluations of the error classes is determined and output via a user interface. In this way, a user immediately gets an overview of how to rank the overall quality of the software source code. The quality Bewer ¬ obligations of the error classes and / or the overall quality assessment is based in this case preferably to predetermined numerical values. With such measures, the overall quality assessment can be determined in particular in a simple manner by summing up the measures of the quality assessments of the error classes.
In einer besonders bevorzugten Ausführungsform der Erfindung ist das Verfahren derart ausgestaltet, dass über eine Benut¬ zerschnittstelle eine Soll-Qualität des Softwarequellcodes eingebbar ist, wobei die Soll-Qualität mit der Ist-Qualität gemäß den Qualitätsbewertungen der Fehlerklassen und/oder der Gesamtqualitätsbewertung verglichen wird und das entsprechende Vergleichsergebnis über eine Benutzerschnittstelle ausge¬ geben wird. Hierdurch können selbsttätig durch einen Benutzer bestimmte erwünschte Qualitätsanforderungen vorgegeben werden, wobei das Verfahren automatisiert diese Qualitätsanfor- derungen berücksichtigt und ausgibt, ob diese Qualitätsanfor¬ derungen durch den Softwarequellcode tatsächlich erfüllt werden .In a particularly preferred embodiment of the invention, the method is configured such that a Benut ¬ cut constitutes a target quality of the software source code can be entered, wherein the target quality is compared with the actual quality in accordance with the quality of the error classes and / or the overall quality and the corresponding comparison result is issued via a user interface ¬ . In this way, certain desirable quality requirements can be set automatically by a user, the method automates these quality requirements into consideration, and outputs, if these Qualitätsanfor ¬ requirements will be met by the software source code.
Vorzugsweise werden die Qualitätsbewertungen der Fehlerklas- sen und/oder der Gesamtqualitätsbewertung in einem abrufbaren Speicher hinterlegt, wodurch eine Qualitätshistorie von ver¬ schiedenen Versionen von Softwarequellcodes im Speicher gespeichert wird. Auf diese Weise bekommt ein Benutzer sehr leicht einen Überblick darüber, wie sich die Qualität über die verschiedenen Softwareversionen hinweg verändert hat und ob die durchgeführten Qualitätsmaßnahmen in der Vergangenheit auch tatsächlich zu einer signifikanten Qualitätsverbesserung der Software geführt haben. Vorzugsweise sind in der gene¬ rierten Qualitätshistorie auch die jeweiligen Ist-Qualitäten und Soll-Qualitäten der Versionen des Softwarequellcodes hinterlegt .Preferably, the quality assessments of the error classes and / or the overall quality evaluation are stored in a retrievable memory, whereby a quality history of different versions of software source codes is stored in the memory. In this way, a user gets a lot It is easy to get an overview of how the quality has changed across the different software versions, and whether the quality measures taken in the past have actually led to a significant improvement in the quality of the software. Preferably, in the genetic ¬ tured quality history and the respective actual and desired qualities qualities of the versions of the software source code are stored.
In einer weiteren, besonders bevorzugten, Ausführungsform der Erfindung werden aus den Qualitätsbewertungen der Fehlerklassen Änderungsanforderungen an den Softwarequellcode generiert, und aus den Änderungsanforderungen werden Änderungsmitteilungen erstellt, wobei die Änderungen in einer Ände- rungsmitteilung jeweils einer Person oder einem Personenkreis zugeordnet sind, der für die Durchführung der Änderungen in der Änderungsmitteilung verantwortlich ist. Auf diese Weise wird automatisiert eine Zuweisung der im Softwarequellcode durchzuführenden Änderungen an den dafür Verantwortlichen ge- neriert . Vorzugsweise können darüber hinaus Kriterien über eine Benutzerschnittstelle eingegeben werden, wobei diese Kriterien bei der Generierung der Änderungsanforderungen zu berücksichtigen sind. Solche Kriterien sind beispielsweise angepasste Qualitätsbewertungen, d.h. es wurde manuell durch Experten ermittelt, dass die Qualität aufgrund äußerer Um¬ stände etwas anders zu bewerten ist, als dies automatisiert im erfindungsgemäßen Verfahren erfolgt ist. Darüber hinaus können beispielsweise Prioritäten betreffend die Behebung der Fehler vorgegeben werden, d.h. es kann festgelegt werden, welche Fehler bevorzugt zu beheben sind. Solche Informationen können dann in die automatisch generierten Änderungsmitteilungen einfließen. In einer besonders bevorzugten Ausführungsform werden die Änderungsmitteilungen jeweils automatisiert der Person oder den Personenkreis übermittelt, der für die Durchführung der Änderungen in der Änderungsmitteilung verantwortlich ist. Beispielsweise kann der verantwortlichen Person die Änderungsmitteilung automatisiert über eine E-Mail als Datei übermittelt werden. In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens können die Änderungsmitteilungen ferner Hinweise zur Durchführung der Änderung und/oder eine Abschätzung des Auf- wands der Änderungen enthalten. Es kann hierbei eine beliebi¬ ge Metrik zur Bestimmung des Aufwands verwendet werden, bei¬ spielsweise eine Kostenmetrik, welche als Ergebnis die Mann¬ stunden angibt, welche gebraucht werden, um die Änderung durchzuführen .In a further, particularly preferred, embodiment of the invention, change requests for the software source code are generated from the quality evaluations of the error classes, and change messages are created from the change requests, wherein the changes in a change message are respectively assigned to a person or group of persons who are responsible for the change Implementation of the changes in the change notification. In this way, an automatic assignment of the changes to be made in the software source code to the responsible person is generated. In addition, criteria may moreover be entered via a user interface, these criteria being taken into account when generating the change requests. Such criteria include customized quality reviews, that it was manually calculated by experts that the quality due to external To ¬ stands must be assessed somewhat differently than it automates the process of this invention is carried out is. In addition, for example, priorities concerning the correction of the errors can be specified, ie it can be determined which errors are preferably to be remedied. Such information can then be included in the automatically generated change messages. In a particularly preferred embodiment, the change messages are each automatically transmitted to the person or group of people responsible for making the changes in the change notification. For example, the responsible person can be sent the change notification automatically via e-mail as a file. In a further refinement of the method according to the invention, the change messages can also contain instructions for carrying out the change and / or an estimate of the effort of the changes. It can be a beliebi ¬ ge metric for determining expense used herein, game instance that are needed at ¬ a cost metric, which as a result indicates the man ¬ hours to perform the change.
In einer bevorzugten Ausführungsform der Erfindung enthalten die Hinweise zur Durchführung der Änderungen auch Musterlösung zur Änderung des Softwarequellcodes, wobei den Musterlö¬ sungen vorzugsweise jeweils ein Aufwand zur Durchführung der Musterlösung zugeordnet ist.In a preferred embodiment of the invention, the instructions for carrying out the changes also contain a sample solution for changing the software source code, wherein the pattern solutions are preferably each assigned an expense for carrying out the sample solution.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens umfassen die Fehlerklassen Qualitätsfehlerklassen, welche die Fehler nach Qualitätskriterien kategorisieren . Insbe- sondere können die Codierungsfehler einem Qualitätsmodel zu¬ geordnet werden, wodurch eine von einer rein technischen Klassifikation unabhängige Sichtweise auf die Codierungsfehler geschaffen wird.In a further embodiment of the method according to the invention, the error classes include quality error classes which categorize the errors according to quality criteria. In particular, the coding error can be subordinate to a quality model to ¬, which is independent of a purely technical classification view is created on the coding error.
Neben dem oben beschriebenen Verfahren betrifft die Erfindung ferner eine Vorrichtung zur rechnergestützten Bewertung von Softwarequellcode, umfassend: - ein Analysemittel zum Analysieren des Softwarequellcodes unter Berücksichtigung von Parametern umfassend Codie- rungsregeln und/oder Codierungsmetriken, wobei durch das Analysemittel als Analyseergebnis im Softwarequellcode detektierte Fehler ermittelt werden; ein Klassifizierungsmittel zum Klassifizieren der detek- tierten Fehler, indem die detektierten Fehler jeweils zu- mindest einer Klasse aus einer Mehrzahl von Fehlerklassen zugeordnet werden, wobei jeder Fehlerklasse eine über ei¬ ne Benutzerschnittstelle ausgebbare Spezifikation zuge- ordnet ist, welche die Fehler der jeweiligen Fehlerklasse beschreibt; ein Ausgabemittel zum Ausgeben derjenigen Fehlerklassen, welchen detektierte Fehler zugeordnet sind, über eine Be- nutzerschnittstelle .In addition to the above-described method, the invention further relates to a device for computer-aided evaluation of software source code, comprising: an analysis means for analyzing the software source code taking into account parameters including coding rules and / or coding metrics, wherein errors detected by the analysis means as an analysis result in the software source code become; a classification means for classifying the defect detected by the defect detected respectively At the very least be associated with fault classes of a class of a plurality, each fault class conces- an egg over ¬ ne user interface specification outputtable is ordered which describes the errors of the respective error class; an output means for outputting those error classes to which detected errors are associated via a user interface.
Die Erfindung betrifft darüber hinaus ein Computerprogrammprodukt mit einem auf einem maschinenlesbaren Träger gespeicherten Programmcode zur Ausführung des oben beschriebenen erfindungsgemäßen Verfahrens, wenn das Programm auf einem Rechner läuft.The invention further relates to a computer program product having a program code stored on a machine-readable carrier for carrying out the inventive method described above when the program is run on a computer.
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren detailliert beschrieben.Embodiments of the invention are described below in detail with reference to the accompanying drawings.
Es zeigen:Show it:
Fig. 1 eine schematische Darstellung eines Softwareent¬ wicklungsprozesses, in dem das erfindungsgemäße Verfahren eingesetzt wird;Fig. 1 is a schematic illustration in which the inventive method is used a Softwareent ¬ development process;
Fig. 2 eine Ausführungsform einer erfindungsgemäßen Vorrichtung zur rechnergestützten Bewertung von Softwarequellcode .2 shows an embodiment of a device according to the invention for the computer-aided evaluation of software source code.
Im Folgenden wird eine Ausführungsform des erfindungsgemäßen Verfahrens beschrieben, welches die folgenden, bereits oben erwähnten Fehlerklassen enthält: Notations-Konventionen; Typen-Deklarationen und/oder Defini- tionen; Programm-Anweisungen; Speicherprobleme; Software- Protokolle; Design und/oder Architektur; Korrektheit; Zeit¬ verhalten .An embodiment of the method according to the invention is described below, which contains the following error classes already mentioned above: notation conventions; Type declarations and / or definitions; Program instructions; Memory problems; Software protocols; Design and / or architecture; Correctness; Term behavior ¬.
Jeder dieser Fehlerklassen ist eine Spezifikation in der Form einer Beschreibung zugeordnet, welche die bereits im vorange¬ gangen erwähnten folgende Kategorien umfasst: Entwicklungsziel; Verletzung; Ursachen für das Verfehlen des Entwicklungsziels; Korrekturen; Detektionsmechanismus; Aus¬ wirkungen des Verfehlens des Entwicklungsziels.Each of these classes of errors is assigned to a specification in the form of a description that includes the following categories already mentioned in vorange ¬ addressed: Development Goal; Injury; Causes for failing the development goal; Corrections; Detection mechanism; From ¬ effects of missing the development goal.
Im Folgenden wird für jede der oben genannten Fehlerklassen die entsprechende Beschreibung gemäß der soeben genannten Beschreibungskategorien gegeben.In the following, for each of the abovementioned error classes, the corresponding description is given according to the just described description categories.
1. Notationskonventionen1. Notation conventions
A. EntwicklungszielA. Development goal
Die Quellen von Softwareprogrammen sollten so lesbar wie möglich sein, um verständlich und wartbar zu sein. Die Notation der Quellen als Text spielt hier eine wesentliche Rolle. Die Notationen betreffen hierbei insbesondere Namen für Symbole und Artefakte, den Stil und die Dokumentation.The sources of software programs should be as legible as possible to be understandable and maintainable. The notation of sources as text plays an essential role here. In particular, the notations concern names for symbols and artifacts, the style and the documentation.
Namen : Die erforderlichen, in den Anforderungen implizit oder explizit genannten physischen oder virtuellen Phänomene eines Anwendungsbereichs werden systematisch, eindeutig und sowohl für den Fachexperten als auch den Softwareingenieur verständlich bezeichnet.Names: The required physical or virtual phenomena of an application area, implicitly or explicitly stated in the requirements, are described systematically, unambiguously and understandably both by the subject matter expert and by the software engineer.
Stil:Style:
Jede Programmiersprache definiert durch ihre Syntax die Gram¬ matik, d.h., welche Inhalte durch die Programmiersprache auf welche Weise auszudrücken sind. Die Syntax legt nicht fest, in welcher Form (Einrückungen, Klammerungen, Zeilenumbrüche, Formate von Kommentaren etc.) Programme geschrieben werden müssen. Daneben gibt es noch stilistische Regeln und Nuancen, in welchem Kontext welche Sprachkonstrukte wie einzusetzen sind, und zwar unabhängig davon, ob auch alternative Formu- lierungen aufgrund der Syntax der Programmiersprache möglich sind. Entwicklungsziel im Hinblick auf den Stil ist es, die Programmiersprache aus stilistischer Sicht so zu verwenden, dass die in der Branche etablierten und als qualitativ gut empfundenen stilistischen Regeln eingehalten werden.Any programming language defined by their syntax Gram ¬ matics, ie what content is expressed by the programming language in which way. The syntax does not specify in which form (indents, brackets, line breaks, comment formats, etc.) programs must be written. There are also stylistic rules and nuances in which context which language constructs should be used and how they are used, regardless of whether alternative formulations are possible due to the syntax of the programming language. Design goal in terms of style is to use the programming language from a stylistic point of view that the established in the industry and perceived as good quality stylistic rules are met.
Dokumentation : Die Dokumentation liefert über den Programmcode hinausgehende, wesentliche Hinweise zum Verständnis des Softwarequellco¬ des. Der Softwareentwickler beschreibt hierbei seine über das Design hinausgehenden Entscheidungen.Documentation: The documentation provides, beyond the program code, essential information for understanding the software source code. The software developer here describes his decisions going beyond the design.
B. VerletzungB. Injury
Namen :Name:
Namen oder Bezeichner im Programmcode sind entweder mehrdeutig oder lassen keinen Schluss auf das zugrunde liegende Phä- nomen der Anwendungsdomäne zu. Darüber hinaus lässt es sich oft beobachten, dass einzelne Entwickler oder Entwicklergrup¬ pen ein lokales Vokabular aufbauen, das von Außenstehenden nicht verstanden werden kann.Names or identifiers in the program code are either ambiguous or do not allow any conclusion to the underlying phenomenon of the application domain. In addition, it can be observed often that individual developers or Entwicklergrup ¬ pen create a local vocabulary that can not be understood by outsiders.
Stil:Style:
Sowohl eine schlechte Namenswahl als auch ein schlechter Programmierstil führt zu einer Personalisierung der Softwareent¬ wicklung, d.h., der entsprechende Programmtext kann nur noch vom ursprünglichen Entwickler des Programms mit vertretbarem ökonomischen Aufwand gewartet und weiterentwickelt werden.Both a poor choice of name and a poor programming style leads to a personalization of Softwareent ¬ development, ie, the corresponding program text can be maintained and developed only with reasonable economic effort by the original developer of the program.
C. Ursachen für das Verfehlen des EntwicklungszielsC. Causes of failure to achieve the development goal
Fehlende oder sprachlich uneinheitliche Anforderungsspezifi- kationen definieren keinen klaren Wortschatz, der für die Namensgebung herangezogen werden könnte. Daher verwenden die Entwickler frei erfundene Bezeichner, die weder definiert sind noch eindeutig sind.Missing or linguistically inconsistent requirement specifications do not define a clear vocabulary that could be used for naming. Therefore, the developers use fictitious identifiers that are neither defined nor unique.
In älteren Programmiersprachen waren die Länge und der Aufbau von Bezeichnern aus Gründen der Ressourcenknappheit oder aufgrund mangelhafter Compilertechnologie eingeschränkt. Heute findet man immer noch Nachwirkungen dieser Beschränkungen auch bei der Verwendung moderner Programmiersprachen, obwohl keine technische Notwendigkeit mehr dafür besteht.In older programming languages, the length and structure of identifiers was limited due to resource constraints or poor compiler technology. Today, there are still aftereffects of these restrictions even with the use of modern programming languages, although there is no technical need for it.
Codierrichtlinien und die bestmögliche Umsetzung dieser Richtlinien sind nicht bekannt oder werden von dem Softwareentwickler nicht akzeptiert.Coding Guidelines and the best implementation of these guidelines are not known or accepted by the software developer.
Weitere Gründe für das Verfehlen des Entwicklungsziels ist fehlendes Problembewusstsein und/oder fehlendes Gesamtver- ständnis.Other reasons for failing to achieve the development goal are lack of awareness of the problem and / or lack of overall understanding.
D. KorrekturD. Correction
Vorgabe von allgemeinen Namenskonventionen und von pro- jektspezifischen Namenskonventionen. Die projektspezifischen Namenskonventionen regeln den Umgang mit den Begriffen der Domäne, indem beispielsweise ein Glossar wichtiger Begriffe im Kontext des Softwareprojektes vor¬ gegeben wird. - Vorgabe von Programmierrichtlinien, in denen Fragen der Formatierung (Einrückungen, Klammersetzung etc.) definiert sind. Darüber hinaus wird in den Programmierricht¬ linien beschrieben, welche Sprachkonstrukte in welchem Kontext wie zu verstehen sind. - Schulung der MitarbeiterSpecification of general naming conventions and project-specific naming conventions. The project-specific naming conventions regulate the use of the concepts of the domain, for example by a glossary of important terms is given in the context of the software project before ¬. - Specification of programming guidelines in which questions of formatting (indentation, bracketing, etc.) are defined. It also describes the programming guide ¬ lines which language constructs are the context in which to understand how. - Training of employees
Durchführung von Codeüberprüfungen mit dem Schwerpunkt auf Namenswahl im Programmierstil.Conducting code reviews focusing on naming choices in the programming style.
Sog. Reengineering betroffener Codeteile auf der Basis der Namenskonventionen und der Programmierrichtlinien.So-called. Reengineering of affected code parts based on naming conventions and programming guidelines.
E. DetektionsmechanismusE. Detection mechanism
Die Einhaltung von Programmierrichtlinien, d.h. die Einhaltung stilistischer Vorgaben, kann in der Regel automatisiert durch statische Codeanalyse-Werkzeuge sichergestellt werden. Die Einhaltung von Namenskonventionen kann - für allgemeine Namenskonventionen - ebenfalls durch entsprechende statische Codeanalyse-Werkzeuge erfolgen. Die semantisch richtige Ver- wendung von Namen im Kontext der betrachteten Domäne kann nur manuell durch entsprechende Reviews sichergestellt werden.Compliance with programming guidelines, ie compliance with stylistic specifications, can usually be ensured automatically by means of static code analysis tools. Compliance with naming conventions can - for general naming conventions - also be carried out using appropriate static code analysis tools. The semantically correct The use of names in the context of the domain under consideration can only be ensured manually by appropriate reviews.
F. AuswirkungenF. Impact
Der Quellcode wirkt unordentlich und handwerklich schlecht. Uneindeutige Bezeichner verursachen Kommunikationsprobleme. Dies hat direkte Auswirkungen auf die Wartbarkeit des Codes.The source code looks messy and crafty bad. Ambiguous identifiers cause communication problems. This has a direct impact on the maintainability of the code.
2. Typen-Deklarationen und Definitionen2. Type declarations and definitions
A. EntwicklungszielA. Development goal
In einer statisch typisierten Programmiersprache sind alle Bezeichner mit demjenigen Typennamen assoziiert, der am besten zum Verwendungskontext des Bezeichners passt. In diesem Sinne ist der Typname dann gut gewählt, wenn keine Verwen¬ dungsfehler des Bezeichners vorkommen können bzw. auch keine expliziten Typumwandlungen erforderlich sind.In a statically typed programming language, all identifiers are associated with the type name that best fits the usage context of the identifier. In this sense, the type name is then well chosen if no Verwen ¬ tion errors of the identifier can occur or even no explicit type conversions are required.
Der Gültigkeitsbereich von Bezeichnern ist so zu wählen, dass nur jene Typen nach außen sichtbar werden, die auch tatsächlich benötigt werden.The scope of identifiers should be chosen so that only those types that are actually needed are visible to the outside world.
B. VerletzungB. Injury
Eine Verletzung des Entwicklungsziels liegt dann vor, wenn Typen verwendet werden, die im Kontext der Verwendung von Bezeichnern nicht sinnvoll sind. Eine Verletzung des Entwick- lungsziels liegt ferner dann vor, wenn die Deklaration eines Bezeichners so erfolgt, dass dem Verwender eines Bezeichners (z.B. der Parameter einer Methode) aufgrund des verwendeten Typs Implementierungsdetails bekannt werden, die aus sachli¬ cher Sicht nicht bekannt sein müssten. Ursachen für das Verfehlen des EntwicklungszielsA development goal violation exists when using types that are not meaningful in the context of using identifiers. Injury to the development target also exists if the declaration of an identifier is performed so that the user of an identifier can be known (for example the parameters of a method) due to the used type implementation details that should not be known from sachli ¬ cher view. Causes for missing the development goal
In den Programmierrichtlinien werden zu diesem Thema keine Aussagen gemacht. - Mangelhaftes Verständnis der Entwickler für allgemeine softwaretechnische Designaspekte, wie Gestaltung von Schnittstellen, Kopplung und Kohäsion von Typen etc. Mangelhaftes Verständnis der Typkonzepte einer Program¬ miersprache, z.B. Schnittstellenvererbung, Implementie- rungsvererbung, abstrakte Klassen usw.The programming guidelines do not comment on this topic. - Inadequate understanding of the developers for general software technical design aspects, such as design of interfaces, coupling and cohesion of types etc. Inadequate understanding of the concepts of a type Program ¬ programming language, such as interface inheritance, imple- approximately inheritance, abstract classes, etc.
Unzureichende Refactoring nach Design-Änderungen, d.h. es werden die aufgrund eines Refactoring neu geschaffe¬ nen allgemeineren Typen nicht konsistent im gesamten Quelltext nachgezogen, d.h. anstelle der alten Typen verwendet.Inadequate refactoring after design changes, ie it can not be traced, the newly geschaffe ¬ nen due to refactoring more general types consistent throughout the source code, that is used in place of the old types.
Anforderungen sind z.B. bei Schnittstellendefinition nicht definiert oder bekannt. Daher werden hier Typen festgelegt, die später bei der Implementierung korrigiert werden müssen.Requirements are e.g. not defined or known with interface definition. Therefore, types are set here that need to be corrected later in the implementation.
D. KorrekturD. Correction
Schulung der Entwickler mit Fokus auf softwaretechnische Grundlagen des Designs und hinsichtlich der Typkonzepte der jeweiligen Programmiersprache.Training of the developers with a focus on the software engineering basics of the design and the type concepts of the respective programming language.
Verbesserung der Programmierrichtlinien. Systematische Durchführung von Code-Reviews.Improvement of the programming guidelines. Systematic implementation of code reviews.
Es kann sinnvoll sein, Verletzungen im vernünftigen Rahmen oder bei bestimmten Designkonzepten zuzulassen.It may be useful to allow for reasonable injuries or design concepts.
E. DetektionsmechanismusE. Detection mechanism
Fehler hinsichtlich von Typen-Deklarationen und Definitio- nen werden aus dem Regelsatz der Codeanalysatoren oder aus daraus abgeleiteten Steuerungsmetriken ermittelt, z.B. aus der Anzahl an Typkonversionen, der Anzahl an Typverletzungen usw. F. AuswirkungenDefects regarding type declarations and definitions are determined from the rule set of the code analyzers or derived control metrics, such as the number of type conversions, the number of type violations, and so on. F. Impact
Durch die Verwendung von Typkonvertierungs-Operatoren kann es - je nach der Typkonvertierung - zu einem Verlust von Rechengenauigkeit bis hin zum Programmabsturz kommen.The use of type conversion operators can lead to a loss of computational accuracy or even crashes, depending on the type conversion.
Bei Missachtung der in der Softwaretechnik üblichen Sichtbarkeitsregeln für Typen kommt es zu unnötigen Kopplungen zwischen einzelnen Softwareartefakten, welche die Änderbarkeit des Softwarequellcodes negativ beeinflussen.Disregarding the usual software visibility rules for types, there is unnecessary coupling between individual software artifacts, which adversely affect the changeability of the software source code.
3. Programm-Anweisungen3. Program instructions
A. EntwicklungszielA. Development goal
Grundsätzliches Entwicklungsziel ist es, die Strukturie¬ rung des Quellcodes im Kleinen so vorzunehmen, dass damit die üblichen softwaretechnischen Qualitätskriterien er- füllbar sind. Die Strukturierung im Kleinen beschäftigt sich mit folgenden Aspekten:Fundamental development goal is to make the structuring ¬ tion of the source code on a small scale so that so that the usual software engineering quality criteria are ER- be filled. The structuring on a small scale deals with the following aspects:
Komplexität von Ausdrücken, insbesondere von logischen und arithmetischen Ausdrücken.Complexity of expressions, in particular of logical and arithmetical expressions.
Adäquate Verwendung unterschiedlicher Schleifenkonstruk- te.Adequate use of different loop constructions.
Adäquate Verwendung unterschiedlicher Selektionsanweisungen . Komplexität von Funktionen und Methoden.Adequate use of different selection instructions. Complexity of functions and methods.
Es soll eine, zumindest näherungsweise, minimale und nach¬ vollziehbare Sequenz von Anweisungen zur Realisierung der geforderten funktionalen und nicht-funktionalen Merkmale verwendet werden. Dabei ist der konzeptionelle Ablauf in geeig¬ neter Form abzubilden. B. VerletzungIt is an, at least approximately, minimum and executable by ¬ sequence of instructions for realizing the required functional and non-functional features are used. Here, the conceptual flow in geeig ¬ neter shape is to be imaged. B. Injury
Die Codierungsfehler dieser Fehlerklasse sind abhängig von der Art der Anweisung. Entweder enthält die Anweisung seman- tisch falsche Bestandteile oder die Anweisung ist zumindest semantisch fragwürdig, überflüssig, zu komplex oder unvoll¬ ständig.The coding errors of this error class depend on the type of instruction. Contains either the instruction semantically incorrect ingredients or the instruction is at least semantically questionable unnecessary to complex or incomplete ¬ constantly.
C. Ursachen für das Verfehlen des EntwicklungszielsC. Causes of failure to achieve the development goal
Es liegen Zeit- und/oder Ausbildungsmängel bei den Software¬ entwicklern vor.There are time and / or training shortcomings in software developers.
B. KorrekturB. Correction
Es muss zuerst die vom Softwareentwickler verwendete Anwei¬ sung zunächst beschrieben und dann codiert werden. Eine Methode zur Vermeidung von Anweisungsfehlern ist sog. „literate Programming". Die Korrektur kann durch den Entwickler eventu- eil nach einer Schulung vorgenommen werden.It must first be the instruc ¬ solution used by software developers described first and then encoded. One method of avoiding instruction errors is so-called "literate programming." The correction may be made by the developer after training.
E. DetektionsmechanismusE. Detection mechanism
Anweisungsfehler werden aus dem Regelsatz der Codeanalysato- ren und daraus abgeleiteter Steuerungsmetriken detektiert, z.B. aus der Anzahl zweifelhafter, redundanter und unerreichbarer Aussagen.Instruction errors are detected from the rule set of the code analyzers and control metrics derived therefrom, e.g. from the number of dubious, redundant and unattainable statements.
F. AuswirkungenF. Impact
Eine Verletzung des oder der Entwicklungsziele kann - je nach Art der Verletzung - eine negative Auswirkung auf die Korrektheit des Programms haben.A violation of the development goal (s) - depending on the nature of the violation - can have a negative impact on the correctness of the program.
Gibt es keine Auswirkungen auf die Korrektheit, entsteht durch die Verletzung des Entwicklungsziels schwer wartbarer Softwarecode, der wiederum in erster Linie nur von den ur- sprünglichen Entwicklern mit ökonomisch vertretbarem Aufwand gewartet und weiterentwickelt werden kann.If there is no effect on the correctness, the violation of the development goal results in hard-to-maintain software code, which in turn is only used by the original can be maintained and further developed with economically justifiable effort.
4. Speicherprobleme4. Memory problems
A. EntwicklungszielA. Development goal
Entwicklungsziel ist es, mit dem Hauptspeicher sparsam umzu¬ gehen, d.h. nur notwendigen Speicher zum geeigneten Zeitpunkt zu allokieren und ggf. rechtzeitig freizugeben. Darüber hinaus muss sichergestellt werden, dass sich der Hauptspeicherplatz zu jedem Zeitpunkt in einem konsistenten Zustand befindet. Weiterhin muss sichergestellt sein, dass Variablen, die explizit Speicher referenzieren, zu jedem Zeitpunkt in einem konsistenten Zustand sind, d.h. keine ungewollten Null-Werte aufweisen, keine falschen Speicheradressen enthalten, usw.Development goal is to frugal umzu ¬ with the main memory, ie allocate only necessary memory at the appropriate time and possibly release in time. In addition, it must be ensured that the main memory space is in a consistent state at all times. Furthermore, it must be ensured that variables which explicitly reference memory are in a consistent state at all times, ie have no unwanted zero values, contain incorrect memory addresses, etc.
B. VerletzungB. Injury
- Eine Verletzung des Entwicklungsziels liegt dann vor, wenn in unnötiger Weise Speicher allokiert wird und vergessen wird, Speicher rechtzeitig wieder freizugeben. Das Entwicklungsziel kann ferner durch unsachgemäße Ver¬ wendung von Sprachkonstrukten verletzt werden, wobei solche Sprachkonstrukte zu fehlerhaften Manipulationen von Speicherinhalten oder Speicheradressen führen. Operatoren, welche typischerweise unsachgemäß verwendet werden, sind arithmetische Adressoperationen und Typkon- vertierungs-Operatoren .- There is a violation of the development goal if storage is unnecessarily allocated and it is forgotten to release storage in good time. The development objective can be damaged by improper application of language constructs Ver ¬ further, where such language constructs lead to erroneous manipulation of memory contents or memory addresses. Operators that are typically misused are arithmetic address operations and type conversion operators.
C. Ursachen für das Verfehlen des EntwicklungszielsC. Causes of failure to achieve the development goal
Ursachen sind insbesondere Zeit- und Ausbildungsmängel bei den Softwareentwicklern, sowie fehlende Designkonzepte. D. KorrekturCauses are in particular time and training defects with the software developers, as well as missing design concepts. D. Correction
Die Korrektur von Speicherproblemen kann durch den Entwickler selbst, eventuell nach einer Schulung, vorgenommen werden.The correction of memory problems may be made by the developer himself, possibly after training.
E. DetektionsmechanismusE. Detection mechanism
Speicherprobleme können aus dem Regelsatz der Codeanalysato- ren und daraus abgeleiteter Steuerungsmetriken ermittelt wer- den, z.B. aus der Anzahl zweifelhafter oder falscher Aussagen, die den Zustand des Speichers ändern.Memory problems can be determined from the rule set of the code analyzers and control metrics derived therefrom, e.g. from the number of dubious or false statements that change the state of the memory.
F. AuswirkungenF. Impact
Fehler bei der Verwaltung des Speichers führen zu inkonsis¬ tenten Zuständen oder zu hohem Speicherverbrauch und stellen oft indirekt die Realisierung der geforderten funktionalen und nicht-funktionalen Eigenschaften des Programms in Frage, insbesondere die Laufzeitstabilität.Errors in the management of the memory lead to inkonsis ¬ tenten conditions or high memory usage and often provide indirectly the realization of the required functional and non-functional features of the program in question, in particular the term stability.
5. Software-Protokolle5. Software protocols
A. EntwicklungszielA. Development goal
Software-Protokolle beschreiben, in welcher Reihenfolge pro¬ grammtechnisch bestimmte Vorgänge ausgeführt werden sollen. Ein Beispiel eines Software-Protokolls ist z.B. die Veröf¬ fentlichung eines Schnittstellen-Protokolls. Entwicklungsziel ist es hierbei, dass die Software-Protokolle bei der Program- mierung derart berücksichtigt werden, dass das Programm dem Systemzustand konsistent hält. Dafür werden Aufrufreihenfol- gen von Prozeduren definiert und diese an bestimmte Zustände und Eingaben geknüpft. Dies ist z.B. bei asynchronen Syste¬ men, in Fehlersituationen, bei der Verwendung von Nebenläu- figkeit unter Benutzung von mehrfach gleichzeitig verwendeten externen Ressourcen besonders wichtig. B. VerletzungSoftware protocols describe to be in what order executed per ¬ program technically specific operations. An example of a software protocol is as the publica ¬ publication an interface protocol. The development goal here is that the software protocols are taken into account during the programming in such a way that the program keeps the system state consistent. For this purpose, call sequences of procedures are defined and linked to specific states and inputs. This is for example with asynchronous syste ¬ men, in error situations, when using Nebenläu- stiffness particularly important under use of multiple simultaneously used external resources. B. Injury
Das Entwicklungsziel ist verletzt, wenn Prozeduren in einer Reihenfolge oder unter den falschen Bedingungen aufgerufen werden, so dass ein inkonsistenter Systemzustand entsteht.The development goal is violated when procedures are called in order or under the wrong conditions, resulting in an inconsistent system state.
C. Ursachen für das Verfehlen des EntwicklungszielsC. Causes of failure to achieve the development goal
Die implizit oder explizit vorgegebenen Protokolle werden nicht beachtet. Implizite Protokolle sind nicht ausreichend bekannt bzw. dokumentiert.The implicitly or explicitly specified protocols are ignored. Implicit protocols are not sufficiently known or documented.
D. KorrekturD. Correction
Implizite Protokolle sollten verständlich dokumentiert wer¬ den. Die Entwickler sollten bezüglich der verwendeten Protokolle geschult werden.Implicit protocols should of course documented ¬ to. Developers should be trained on the protocols used.
E. DetektionsmechanismusE. Detection mechanism
Eine Detektion der Verletzung von Software-Protokollen kann durch manuelle Reviews, der Analyse von Aufrufbäumen mit Da- tenflussanalyse oder der verwendeten Automaten erfolgen. Die Protokolle können auch automatisiert durch statische und dy- namische Codeanalyse-Werkzeuge überprüft werden.Detection of violation of software protocols can be done by manual reviews, the analysis of call trees with data flow analysis or the used machines. The logs can also be checked automatically using static and dynamic code analysis tools.
F. AuswirkungenF. Impact
Es entsteht ein Softwaresystem in einem inkonsistenten bzw. instabilen Zustand.The result is a software system in an inconsistent or unstable state.
6. Design und Architektur6. Design and architecture
A. EntwicklungszielA. Development goal
Primäres Entwicklungsziel ist es, die Architektur und das De¬ sign eines Systems so zu gestalten, dass damit die an dieses System gestellten funktionalen und nicht-funktionalen Anfor- derungen erfüllt werden und auch erwartete Änderungen und Erweiterungen der Anforderungen im Design bzw. in der Architektur antizipiert sind. Neben den produkt- und projektspezifi¬ schen Anforderungen müssen die Architektur und das Design allgemeine softwaretechnische Qualitätsanforderungen erfül¬ len. Diese Anforderungen sind insbesondere:The primary design goal is to make the architecture and De ¬ sign of a system so that so that made on this system functional and non-functional require- and expected changes and extensions of the requirements in the design or in the architecture are anticipated. In addition to the product and projektspezifi ¬ specific requirements, the architecture and design have general technical software quality requirements fulfillment ¬ len. These requirements are in particular:
Sicherstellung hoher, insbesondere funktionaler Kohäsion innerhalb eines Moduls oder eines Subsystems. Sicherstellung geringer Kopplung zwischen Modulen inner- halb eines Subsystems bzw. zwischen Subsystemen.Ensuring high, in particular functional, cohesion within a module or subsystem. Ensuring low coupling between modules within a subsystem or between subsystems.
Angemessene Komplexität im Sinne der von einem Modul o- der einem Subsystem zur Verfügung gestellten Methoden bzw. Typen.Adequate complexity in terms of the methods or types provided by a module or subsystem.
B. VerletzungB. Injury
Verletzungen des Entwicklungsziels liegen dann vor, wenn die definierten funktionalen und nicht-funktionalen Anforderungen aufgrund eines schlecht gewählten Designs oder einer schlecht gewählten Architektur nicht erfüllt werden können. Eine Verletzung liegt auch dann vor, wenn zwar die projekt- oder pro- dukt-spezifischen Anforderungen erfüllt sind, aber Kopplung, Kohäsion und Komplexität nicht angemessen sind.Violations of the development goal exist if the defined functional and non-functional requirements can not be fulfilled due to a poorly chosen design or a poorly chosen architecture. An injury exists even if the project- or product-specific requirements are met, but coupling, cohesion and complexity are not appropriate.
C. Ursachen für das Verfehlen des EntwicklungszielsC. Causes of failure to achieve the development goal
Ursachen sind insbesondere eine fehlende Architektur für das zu entwickelnde Softwaresystem.Causes are in particular a missing architecture for the software system to be developed.
Weitere Ursachen sind fehlende Zeit und Steuerung der Umset¬ zung der Architektur bzw. Mangel an Ressourcen für die systematische Restrukturierung von Softwaresystemen.Other causes are lack of time and control of imple ¬ Zung architecture and lack of resources for the systematic restructuring of software systems.
Weitere Ursachen sind unnötige Beziehungen innerhalb des Softwaresystems sowie die Zerteilung des Systems nicht nach architektonischen Kriterien, wie z.B. Kopplung und Kohäsion, sondern nach Standort oder Bearbeiter. Eine weitere Ursache ist, dass das Softwaresystem wegen Zeit¬ mangel nicht ausreichend gepflegt wurde.Other causes include unnecessary relationships within the software system as well as fragmentation of the system, not by architectural criteria, such as coupling and cohesion, but by location or engineer. Another cause is that the software system has not been adequately maintained due time ¬ lack.
D. KorrekturD. Correction
Es muss bei der Entwicklung des Softwarequellcodes ein Archi¬ tekt oder Projektleiter (falls kein Architekt vorhanden) eingesetzt werden.It must (if not an architect any) are used in the development of a software source code Archi ¬ TEKT or project.
D. DetektionsmechanismusD. Detection mechanism
Die Ermittlung von Fehlern in Design oder Architektur kann manuell oder durch ein Analysetool (z.B. Sotograph) erfolgen,The determination of errors in design or architecture can be done manually or by an analysis tool (e.g., Sotograph),
F. AuswirkungenF. Impact
Entwicklungs- und Wartungskosten steigen. Im Extremfall kann das System nicht mehr gewartet werden und muss neu geschrie¬ ben werden.Development and maintenance costs increase. In extreme cases, the system can no longer be maintained and must be re geschrie ¬ ben.
7. Korrektheit7. Correctness
A. EntwicklungszielA. Development goal
Unter Korrektheit wird hier nicht das explizite Übereinstim¬ men einer Lösung mit spezifizierten Anforderungen verstanden, Vielmehr geht es aus Sicht der internen Codequalität darum, jene Codestellen zu identifizieren, die unabhängig von der konkreten Anforderung inkorrekt sein müssen.Under correctness not the explicit Convention Stim ¬ men a solution is understood to specified requirements here Rather, it is the view of the internal code quality is to identify those codes that must be incorrect regardless of the actual requirement.
B. VerletzungB. Injury
Eine Verletzung liegt dann vor, wenn der Quelltext offensichtliche Fehler enthält, die unabhängig von den konkreten Anforderungen sind. Beispiele dafür sind Verzweigungen inAn injury occurs when the source code contains obvious errors that are independent of the specific requirements. Examples are branches in
Switch-Anweisungen, die nie erreicht werden können, oder unbenutzte lokale Variablen. C. Ursachen für das Verfehlen des EntwicklungszielsSwitch statements that can never be reached, or unused local variables. C. Causes of failure to achieve the development goal
Hier liegen meist Verständnismängel beim Programmierer oder logische Codierungsfehler vor.Here are usually lack of understanding with the programmer or logical coding errors.
D. KorrekturD. Correction
Eine Korrektur von Verständnisfehlern kann durch entsprechende Schulung der Entwickler erfolgen. Codierungsfehler können durch den Entwickler selbst korrigiert werden.A correction of comprehension errors can be done by appropriate training of the developers. Coding errors can be corrected by the developer himself.
E. DetektionsmechanismusE. Detection mechanism
Es besteht die Möglichkeit, Korrektheitsfehler statisch zu detektieren, wenn eine formale Beschreibung des geforderten Ergebnisses zusammen mit der imperativen Realisierung vorliegt. Hier kann dann, meist nur in Teilbereichen, eine Diskrepanz festgestellt werden. Zusätzlich können hier Code- Reviews und Inspektionen zum Auffinden dieser Fehler durchge- führt werden.It is possible to statically detect correctness errors if there is a formal description of the required result together with the imperative realization. Here, then, usually only in some areas, a discrepancy can be found. In addition, code reviews and inspections can be performed to find these errors.
F. AuswirkungenF. Impact
Korrektheitsfehler stellen die Realisierung der impliziten Anforderungen des Softwaresystems in Frage.Correctness errors call into question the realization of the implicit requirements of the software system.
8. Zeitverhalten8. Timing
A. EntwicklungszielA. Development goal
Softwaresysteme müssen mit der ihnen zur Verfügung stehenden Rechenzeit sorgfältig umgehen, und zwar unabhängig davon, welches konkrete Zeitverhalten durch die Spezifikation gefordert wird. Darüber hinaus muss jedes Softwaresystem die rich- tigen Konstrukte für die Synchronisation paralleler Ausführungskontexte korrekt verwenden. Dies betrifft sowohl die Synchronisation in verteilten Systemen als auch die Synchronisation innerhalb eines Betriebssystem-Prozesses. Zeitabhän- gige Systeme und Systeme mit Schnittstellen zu zeitabhängigen Systemen unterliegen hier besonderen Anforderungen.Software systems must be careful with the amount of computing time available to them, regardless of what specific timing is required by the specification. In addition, every software system must correctly use the correct constructs to synchronize parallel execution contexts. This concerns both the synchronization in distributed systems as well as the synchronization within an operating system process. time depen- Existing systems and systems with interfaces to time-dependent systems are subject to special requirements here.
B. VerletzungB. Injury
Eine Verletzung des Entwicklungsziels tritt dann auf, wenn das System unzulängliche Synchronisierungsmechanismen aufweist. Die beobachtbaren Folgen sind Blockaden, Reihenfolgeprobleme, sinnlose Operationen, ineffiziente Algorithmen, un- zulängliche Antwortzeiten und mangelnder Durchsatz.A violation of the development goal occurs when the system has inadequate synchronization mechanisms. The observable consequences are blockages, sequencing problems, pointless operations, inefficient algorithms, inadequate response times, and poor throughput.
C. Ursachen für das Verfehlen des EntwicklungszielsC. Causes of failure to achieve the development goal
Das Softwaresystem wurde nur für einen Verarbeitungskontext entworfen, entwickelt und getestet. Bei den Entwicklern des Systems liegen keine Erfahrungen mit nebenläufigen Systemen vor, d.h. mit Systemen mit mehreren gleichzeitig abgearbeite¬ ten Verarbeitungskontexten.The software system was designed, developed and tested only for a processing context. The developers of the system have no experience with concurrent systems, ie systems with several simultaneously processed processing contexts .
D. KorrekturD. Correction
Eine Korrektur kann durch Schulung der Mitarbeiter, durch ReDesign des Softwarecodes oder durch Codekorrektur erfolgen.Correction can be done by staff training, software code re-design or code correction.
E. DetektionsmechanismusE. Detection mechanism
Fehler im Zeitverhalten können durch Datenflussanalyse über Aufrufgraphen oder durch Überprüfung von Codierungsregeln de- tektiert werden.Errors in the time behavior can be detected by data flow analysis via call graphs or by checking coding rules.
F. AuswirkungenF. Impact
Systeme mit Mängeln im Zeitverhalten sind instabil, unzuverlässig und haben Schwierigkeiten, die geforderten Antwortzei- ten bzw. den geforderten Durchsatz zu gewährleisten.Systems with shortcomings in the time response are unstable, unreliable and have difficulty in ensuring the required response times or the required throughput.
Neben den oben beschriebenen acht Fehlerklassen können ggf. noch weitere Fehlerklassen auftreten, welche beispielsweise in einer Kategorie „Sonstiges" zusammengefasst sind. Dort sind technologie-, domänen- oder projektspezifische Fehler¬ klassen gesammelt.In addition to the eight error classes described above, further error classes may possibly occur, for example are summarized in an "Other" category. There, domain or project-specific error ¬ classes are technology- collected.
Fig. 1 zeigt ein Flussdiagramm eines Softwareentwicklungspro¬ zesses, in dem eine Ausführungsform des erfindungsgemäßen Verfahrens eingebettet ist. Als Ausgangspunkt des Verfahrens liegt das Softwaresystem in der Form eines Softwarequellcodes SQ vor. Zunächst wird gemäß dem erfindungsgemäßen Verfahren der Softwarequellcode anhand von Codierungsregeln bzw. Metriken analysiert, was durch Schritt 1 angedeutet ist. Als Er¬ gebnis werden entsprechende Codierungsfehler ER klassifi¬ ziert, d.h. in entsprechende Fehlerklassen EC eingeteilt. Zur Analyse des Softwarecodes können bekannte statische Codeana- lyse-Werkzeuge oder andere Methoden verwendet werden, wie z.B. Standard-Prüfprozeduren. Die Prüfprozeduren und deren Parameter können beispielsweise aus der letzten Iteration des Projektes, d.h. der letzten Softwareversion, stammen. Hierbei sind insbesondere die Codierungsregeln bzw. Metriken entspre- chend vorgegebener Anforderungen angepasst.Fig. 1 shows a flow diagram of a Softwareentwicklungspro ¬ zesses, in which an embodiment of the inventive method is embedded. As a starting point of the method, the software system is in the form of a software source code SQ. First, according to the inventive method, the software source code is analyzed on the basis of coding rules or metrics, which is indicated by step 1. As a result, he ¬ be appropriate coding errors ER classifi ¬ ed, that is divided into error classes EC. For analyzing the software code, known static code analysis tools or other methods may be used, such as standard test procedures. The test procedures and their parameters can come, for example, from the last iteration of the project, ie the last software version. In particular, the coding rules or metrics are adapted in accordance with predefined requirements.
Nach der Erzeugung der entsprechenden Fehlerklassen wird in einem Schritt 2 eine Gesamtbeurteilung der Qualität des gewählten Parametersatzes der Prüfprozeduren durch Experten durchgeführt. Es erfolgt eine Auswahl der Grenzwerte in Ab¬ hängigkeit von Domänen, Architektur und Softwaretechnologie. Im Schritt 201 wird dann überprüft, ob die Fehlerklassen, welche mit dem erfindungsgemäßen Verfahren automatisiert ermittelt wurden, sich mit der in Schritt 2 vorgenommenen Ge- samtbeurteilung durch Experten decken. Sollte dies nicht der Fall sein (N = Nein) , erfolgt im Schritt 3 eine Erweiterung und Anpassung der Codierungsregeln und Codierungsmetriken. Dabei fließen manuelle Regeln MR und Erfahrung E ein. Ein derart angepasster Regelsatz R fließt dann in das erfindungs- gemäße Verfahren ein, wobei mit dem angepassten Regelsatz dann wieder im Schritt 1 die entsprechenden Fehler ER und Fehlerklassen EC ermittelt werden. Die Schritte 1, 2, 201 und 3 werden so lange iteriert, bis im Schritt 201 festgestellt wird, dass das Ergebnis der Experten sich mit dem automati¬ siert ermittelten Ergebnis des erfindungsgemäßen Verfahren deckt. In diesem Fall (Y = Ja) wird zu Schritt 4 übergegan¬ gen .After the generation of the corresponding error classes, an overall assessment of the quality of the selected parameter set of the test procedures by experts is carried out in a step 2. There is a selection of the limits in Ab ¬ dependence of domains, Architecture and Software Technology. In step 201, it is then checked whether the error classes, which were determined automatically with the method according to the invention, coincide with the overall assessment made in step 2 by experts. If this is not the case (N = No), an extension and adaptation of the coding rules and coding metrics takes place in step 3. In doing so, manual rules MR and experience E are incorporated. A set of rules R adapted in this way then flows into the method according to the invention, with the matched set of rules then again determining the corresponding errors ER and error classes EC in step 1. Steps 1, 2, 201 and 3 are iterated until determined in step 201 is that the result of the expert coincides with the automatic ¬ Siert detected result of the inventive method. In this case (Y = yes) on Gegan ¬ gen will to step 4.
Im Schritt 4 erfolgt eine Vereinbarung oder Anpassung von Qualitätszielen mit den Verantwortlichen (Teilprojektleiter oder deren Qualitätssicherungs-Verantwortlichen) . Hierbei werden insbesondere zu erreichende Qualitätsziele vereinbart bzw. bereits festgelegte Qualitätsziele angepasst.In step 4, an agreement or adaptation of quality objectives with the responsible persons (subproject leader or their quality assurance officers) takes place. In particular, the quality goals to be achieved are agreed or already set quality targets are adjusted.
Im Schritt 5 wird die Ist-Qualität des Softwarequellcodes mit der Soll-Qualität verglichen. Gemäß Schritt 6 wird dann ein Analyseergebnis ausgegeben, welches für die vorliegende Soft- warequellcodeversion den Vergleich von Soll-Qualität und Ist- Qualität enthält. Diese Analyse wird im Schritt 7 in einem Speicher gespeichert, in dem die Qualitätshistorie von vor¬ hergehenden Softwarequellcodeversionen hinterlegt ist.In step 5, the actual quality of the software source code is compared with the target quality. According to step 6, an analysis result is then output, which contains the comparison of target quality and actual quality for the present software source code version. This analysis is stored in Step 7 in a memory, in which the quality history is deposited by reciprocating before ¬ software source code versions.
Im Schritt 8 erfolgt schließlich eine manuelle Prüfung derFinally, in step 8, a manual check of the
Analyseergebnisse, wobei eventuell Änderungen im Hinblick auf die im nächsten Schritt generierten Änderungsanforderungen durchgeführt werden. Man nennt diese Analyse auch „Code Qua- lity Control". Hierbei wird der Code nochmals überprüft und es werden eventuell Anpassungen der Qualitätsbewertungen vorgenommen bzw. Prioritäten im Hinblick auf durchzuführende Änderungen festgelegt.Analysis results, possibly with changes made to the change requests generated in the next step. This analysis is also known as "code quality control." Here, the code is checked again, and adjustments to the quality assessments may be made or priorities set with regard to changes to be made.
Im Schritt 9 erfolgt schließlich die automatische Generierung der Änderungsanforderungen sowie die automatische Erstellung von Änderungsmitteilungen an die entsprechenden Verantwortlichen, eventuell mit einem Lösungshinweis und einer Kosten¬ schätzung. Lösungshinweise, insbesondere Musterlösungen, werden dabei aus einer Lösungsdatenbank LB entnommen.In step 9, finally, is carried out the automatic generation of the change requests and the automatic generation of notifications of changes to the corresponding controller, possibly with a solution of a note and cost ¬ estimate. Solution notes, in particular sample solutions, are taken from a solution database LB.
Schließlich werden im Schritt 10 die gemäß den Änderungsmit¬ teilungen an die Verantwortlichen übermittelten Änderungen in dem Softwarequellcode eingebaut und schließlich im Schritt 11 integriert. Als Ergebnis erhält man im Schritt 12 schließlich eine neue Version des Softwaresystems mit neuem Software¬ quellcode SQ. Der neue Quellcode fließt dann wieder in Schritt 1 des Verfahrens zur erneuten Überprüfung der neuen Version ein.Finally, the changes communicated to the managers according to the Änderungsmit ¬ distributions are incorporated in the software source code in step 10 and finally in step 11 integrated. As a result, we finally obtain a new version of the software system with new software source code SQ ¬ in step 12th The new source code then returns to step 1 of the new revision review process.
Die vorangegangen Schritte 10 bis 12 sind Standardschritte eines Softwareerstellungsprozesses. Die Durchführung der zu¬ vor dargelegten Schritte 2 bis 9 basiert demgegenüber ganz essentiell auf der gemäß der Erfindung entwickelten Fehlerklassifikation. Im Besonderen erlaubt die Fehlerklassifikati¬ on :The preceding steps 10 to 12 are standard steps of a software creation process. By contrast, the implementation of steps 2 to 9 set forth above is essentially based on the error classification developed according to the invention. In particular, allows Fehlerklassifikati ¬ on:
Die Definition von Zielvorgaben auf einer allgemeinen, abstrakten Ebene, die durch die Klassifikation vorgege- ben ist und welche dazu geeignet ist, von Teilprojekt¬ leitern bzw. Qualitätsverantwortlichen verstanden zu werden .The definition of targets on a general abstract plane ben by the classification accordingly and this which is adapted to be understood by Project ¬ heads or quality manager.
Die systematische Gesamtbeurteilung des Softwarequellco¬ des in einer Art und Weise, dass Aussagen darüber ge- macht werden können, welche technischen Problembereiche ganz besonders gut oder ganz besonders schlecht zu be¬ werten sind. Diese Aggregation, die automatisch einhergeht mit der Beurteilung der Softwarequalität, erleichtert auch die Maßnahmenplanung wesentlich. - Den leichteren Vergleich von Soll-Qualität und Ist- Qualität des betrachteten Softwarequellcodes, da der Vergleich nicht auf der Ebene einzelner Metriken erfolgen muss, sondern systematisch auf höherer Ebene durch die entsprechende Klassifikation festgelegt wird. - Die Erstellung von Änderungsmitteilungen an die Verantwortlichen, weil eventuelle Lösungshinweise schon ganz allgemein zu einer Problemklasse zugeordnet werden kön¬ nen und nicht der einzelnen Metrik bzw. den einzelnen Regeln zugeordnet werden müssen.The systematic overall assessment of Softwarequellco ¬ of in a manner that statements can be achie- ved what technical problem areas are particularly good or particularly bad to be ¬ values. This aggregation, which automatically accompanies the evaluation of the software quality, also facilitates the planning of measures considerably. - The easier comparison of target quality and actual quality of the considered software source code, since the comparison does not have to be made at the level of individual metrics, but is systematically determined at a higher level by the corresponding classification. - The creation of change notifications to those responsible because any solution hints are already generally assigned to a class of problems not to be associated with Kings ¬ nen and the individual or the individual metric rules.
Durch die soeben beschriebene Ausführungsform des erfindungs¬ gemäßen Verfahrens wird eine automatisierte Verbesserung der Qualität eines Softwarequellcodes mittels eines gezielten Be- handelns von im Softwarequellcode enthaltenen Fehlern erreicht. Dabei sind verschiedene Fehlerklassen vorgegeben, und diesen Fehlerklassen sind Detektionsmechanismen zum Detektie- ren der Fehler zugeordnet. Der Softwarequellcode wird mittels der Detektionsmechanismen überprüft, und dabei detektierte Fehler werden einer Fehlerklasse zugeordnet. Erfindungsgemäß können unterschiedliche Arten von im Softwarequellcode ent¬ haltenen Fehlern systematisch und effizient detektiert und behandelt werden. Das Verfahren reduziert durch den erhöhten Automatisierungsgrad und die Fokussierbarkeit auf die kriti¬ schen technischen Aspekte den Aufwand für die Steuerung der Softwarecodequalität erheblich. Es bildet eine Brücke von den Fehler-Detektionsverfahren der klassischen Codeanalyse zu gezielten Verbesserungsmaßnahmen, welche die Codequalität effi- zient erhöhen.Through the just described embodiment of the method according ¬ invention is an automated improving the quality of a software source code by way of a targeted loading of errors contained in the software source code. Different error classes are predefined, and these error classes are assigned detection mechanisms for detecting the errors. The software source code is checked by the detection mechanisms, and detected errors are assigned to an error class. According to different types of the software source code ent ¬ preserved errors can be detected and treated systematically and efficiently. The procedure reduces the increased degree of automation and the focus down to the kriti ¬ rule technical aspects of the effort to control the software code quality considerably. It forms a bridge from the error detection methods of classical code analysis to targeted improvement measures, which increase the code quality efficiently.
Fig. 2 zeigt ein Ausführungsbeispiel einer Vorrichtung, mit der das erfindungsgemäße Verfahren realisiert werden kann. Die Vorrichtung umfasst Benutzerschnittstellen, welche in ei- ner Präsentationsschicht PL zusammengefasst sind. Beispiele solcher Benutzerschnittstellen, mit denen die Ergebnisse des erfindungsgemäßen Verfahrens angezeigt werden, sind Laptops LP, eine Workstation WS sowie ein Drucker P. Die Benutzerschnittstellen wechselwirken mit verschiedenen Modulen, die zu einer Anwendungsschicht AL zusammengefasst wird. Es ist hierbei ein Modul Ml vorgesehen, der einen Reportgenerator darstellt. Dieses Modul liefert als Ergebnis die gemäß der Erfindung erstellten Änderungsmitteilungen. Darüber hinaus ist ein Interaktionsmodul M2 vorgesehen, welche die Schnitt- stelle zur Präsentationsschicht PL darstellt. Das eigentliche erfindungsgemäße Verfahren, d.h. die Klassifikation der Fehler erfolgt im Modul M3, welches einen Bewerter darstellt. Im Modul M5 erfolgt der Vergleich zwischen der ermittelten Soll- Qualität und der Ist-Qualität. Darüber hinaus ist ein Statis- tikmodul M7 vorgesehen, welches statistische Auswertungen be¬ züglich der gefundenen Fehler durchführt. Ferner ist eine Datenschnittstelle als Modul M6 vorgesehen, welches eine Schnittstelle hin zu der nachfolgend erläuterten Datenschicht DL darstellt. Darüber hinaus ist als zentrales Modul M4 in der Anwendungsschicht AL eine Steuereinheit vorgesehen, wel¬ che die Interaktion zwischen den anderen Modulen steuert.Fig. 2 shows an embodiment of a device with which the inventive method can be realized. The device comprises user interfaces, which are combined in a presentation layer PL. Examples of such user interfaces that display the results of the method according to the invention are laptops LP, a workstation WS and a printer P. The user interfaces interact with different modules, which are combined to form an application layer AL. In this case, a module M1 is provided which represents a report generator. As a result, this module provides the change messages created according to the invention. In addition, an interaction module M2 is provided, which represents the interface to the presentation layer PL. The actual method according to the invention, ie the classification of the errors takes place in module M3, which represents an evaluator. Module M5 compares the determined target quality with the actual quality. In addition, a Statistical tikmodul is provided M7, which statistical analysis carried out be ¬ züglich of errors found. Furthermore, a data interface is provided as module M6, which interfaces with the data layer explained below DL represents. In addition, it is provided as a central module M4 in the application layer AL, a control unit, wel ¬ che controls the interaction between the other modules.
Die Datenschicht DL beinhaltet die im erfindungsgemäßen Ver¬ fahren verarbeiteten bzw. erzeugten Daten. Beispielhaft sind drei Datensätze Dl, D2 und D3 angegeben. In der hier beschriebenen Ausführungsform ist der Datensatz Dl ein CM- System (CM = Configuration-Management ) , welches ein projekt- spezifisches Datensystem zur Verwaltung des betrachtetenThe data layer DL contains the data processed or generated in the method according to the invention. By way of example, three data sets D1, D2 and D3 are indicated. In the embodiment described here, the data record Dl is a CM system (CM = Configuration Management), which is a project-specific data system for managing the considered
Softwareprojektes ist. Ferner ist als Datensatz D2 eine Me¬ thodenverwaltung vorgesehen, welche die Methoden der Klassifikation und Fehlerdetektion verwaltet. Dieser Datensatz ist organisationsspezifisch, jedoch projektübergreifend. Ferner ist in der Datenschicht DL die Qualitätshistorie D3 der frü¬ heren Softwareversionen enthalten. Die Qualitätshistorie D3 ist organisations- und projektübergreifend. Software project is. Further, a ¬ Me Thode administration is provided as a data record D2 that manages the methods of classification and error detection. This dataset is organization-specific but cross-project. Furthermore, in the data layer DL the quality history D3 of bre ¬ heren software versions is included. The quality history D3 is cross-organizational and cross-project.

Claims

Patentansprüche claims
1. Verfahren zur rechnergestützten Bewertung von Softwarequellcode (SQ) , bei dem: - der Softwarequellcode (SQ) unter Berücksichtigung von Parametern umfassend Codierungsregeln und/oder Codierungsmetriken analysiert wird, wobei als Analyseergebnis im Softwarequellcode (SQ) detektierte Fehler (ER) ermittelt werden; - die detektierten Fehler (ER) klassifiziert werden, indem sie jeweils zumindest einer Fehlerklasse (EC) aus einer Mehrzahl von Fehlerklassen (EC) zugeordnet werden, wobei jeder Fehlerklasse (EC) eine über eine Benutzerschnitt¬ stelle ausgebbare Spezifikation zugeordnet ist, welche die Fehler (ER) der jeweiligen Fehlerklasse (EC) be¬ schreibt; diejenigen Fehlerklassen (EC) , welchen detektierte Fehler (ER) zugeordnet sind, über eine Benutzerschnittstelle ausgegeben werden.1. A method for computer-aided evaluation of software source code (SQ), in which: - the software source code (SQ) is analyzed taking into account parameters including coding rules and / or coding metrics, wherein as an analysis result in the software source code (SQ) detected errors (ER) are determined; - The detected errors (ER) are classified by each of at least one error class (EC) from a plurality of error classes (EC) are assigned, each error class (EC) is assigned via a user interface ¬ pretext specification that the errors (ER) of the respective error class (EC) be ¬ writes; those error classes (EC) associated with detected errors (ER) are output via a user interface.
2. Verfahren nach Anspruch 1, bei dem jeder Fehlerklasse (EC) eine der folgenden programmiertechnischen Kategorien zugeordnet ist, welche über eine Benutzerschnittstelle ausgebbar sind: - eine Kategorie betreffend Notations-Konventionen;2. The method of claim 1, wherein each error class (EC) is associated with one of the following programming categories, which can be output via a user interface: - a category relating to notation conventions;
- eine Kategorie betreffend Typen-Deklarationen und/oder Definitionen;a category concerning type declarations and / or definitions;
- eine Kategorie betreffend Programm-Anweisungen; eine Kategorie betreffend Speicherprobleme: - eine Kategorie betreffend Software-Protokolle; eine Kategorie betreffend das Design und/oder die Archi¬ tektur des Softwarequellcodes (SQ) ; eine Kategorie betreffend die Korrektheit des Software¬ quellcodes (SQ) ; - eine Kategorie betreffend das Zeitverhalten bei der Aus¬ führung des Softwarequellcodes (SQ) . a category concerning program instructions; a category regarding memory problems: - a category regarding software protocols; relating to a category, the design and / or the Archi ¬ ture of the software source code (SQ); A category relating to the correctness of the software source code ¬ (SQ); - A category relating to the time response for the off ¬ management of software source code (SQ).
3. Verfahren nach Anspruch 1 oder 2, bei dem die Fehlerklassen (EC) den programmiertechnischen Kategorien über den De- tektionsmechanismus zugeordnet werden, mit dem Fehler (ER) einer Fehlerklasse (EC) identifiziert werden.3. Method according to claim 1 or 2, in which the error classes (EC) are assigned to the programming-technical categories via the detection mechanism, with the error (ER) of an error class (EC) being identified.
4. Verfahren nach Anspruch 3, bei dem die Spezifikation der jeweiligen Fehlerklasse (EC) eine oder mehrere, insbesondere alle, der folgenden Beschreibungen umfasst: eine Beschreibung eines Entwicklungsziels, welches durch die Behebung der Fehler (ER) der entsprechenden Fehlerklasse (EC) erreicht werden soll;4. The method of claim 3, wherein the specification of the respective error class (EC) comprises one or more, in particular all, of the following: a description of a development goal achieved by remedying the errors (ER) of the corresponding error class (EC) shall be;
- eine Beschreibung der Verletzung des Entwicklungsziels, welche angibt, bei welchen Fehlern (ER) in der jeweili¬ gen Fehlerklasse (EC) das Entwicklungsziel nicht er- reicht wird;Is a description of the violation of the development objective, which indicates in which errors (ER) in the jeweili ¬ gen error class (EC) the development goal not achieved -;
- eine Beschreibung der Ursachen für das Verfehlen des Entwicklungsziels;- a description of the reasons for failing the development goal;
- eine Beschreibung der möglichen Korrekturen im Softwarequellcode (SQ) , um das Entwicklungsziel zu erreichen; - eine Beschreibung der Detektionsmechanismen, welche angibt, wie Fehler (ER) in der jeweiligen Fehlerklasse (EC) detektiert werden. eine Beschreibung der Auswirkungen des Verfehlens des Entwicklungsziels .a description of the possible corrections in the software source code (SQ) to achieve the development goal; a description of the detection mechanisms, which indicates how errors (ER) are detected in the respective error class (EC). a description of the effects of the failure to achieve the development goal.
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Fehlerklassen (EC) in Hierarchieebenen eingeteilt sind.5. The method according to any one of the preceding claims, wherein the error classes (EC) are divided into hierarchy levels.
6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem detektierte Fehler (ER) nach vorgegeben Kriterien gefiltert werden .6. The method according to any one of the preceding claims, in which detected errors (ER) are filtered according to predetermined criteria.
7. Verfahren nach einem der vorhergehenden Ansprüche, bei dem eine Qualitätsbewertung der detektierten Fehler (ER) durchge- führt wird und für jede ausgegebene Fehlerklasse (EC) eine Qualitätsbewertung der Fehlerklasse (EC) auf der Basis der darin enthaltenen Fehler (ER) über eine Benutzerschnittstelle ausgegeben wird. 7. Method according to one of the preceding claims, in which a quality evaluation of the detected errors (ER) is carried out and, for each error class (EC) issued, a quality assessment of the error class (EC) on the basis of the errors (ER) contained therein User interface is output.
8. Verfahren nach Anspruch 7, bei dem aus den Qualitätsbewertungen der Fehlerklassen (EC) eine Gesamtqualitätsbewertung des Softwarequellcodes (SQ) ermittelt und über eine Benutzer- schnittsteile ausgegeben wird.8. The method of claim 7, wherein from the quality assessments of the error classes (EC) an overall quality rating of the software source code (SQ) is determined and output via a user interface parts.
9. Verfahren nach Anspruch 7 oder 8, bei dem die Qualitätsbewertungen der Fehlerklassen (EC) und/oder die Gesamtqualitätsbewertung auf Maßzahlen beruhen.9. The method according to claim 7 or 8, wherein the quality assessments of the error classes (EC) and / or the overall quality assessment are based on measures.
10. Verfahren nach Anspruch 9, bei dem die Gesamtqualitätsbe¬ wertung die Summe der Maßzahlen der Qualitätsbewertungen der Fehlerklassen (EC) ist.10. The method of claim 9, wherein the Gesamtqualitätsbe ¬ evaluation is the sum of the measures of the quality ratings of error classes (EC).
11. Verfahren nach einem der Ansprüche 7 bis 10, bei dem das Verfahren derart ausgestaltet ist, dass über eine Benutzer¬ schnittstelle eine Soll-Qualität des Softwarequellcodes (SQ) eingebbar ist, wobei die Soll-Qualität mit der Ist-Qualität gemäß den Qualitätsbewertungen der Fehlerklassen (EC) und/oder der Gesamtqualitätsbewertung verglichen wird und das entsprechende Vergleichsergebnis über eine Benutzerschnitt¬ stelle ausgegeben wird.11. The method according to any one of claims 7 to 10, wherein the method is configured such that via a user ¬ interface, a target quality of the software source code (SQ) is entered, the target quality with the actual quality according to the quality ratings the error classes (EC) and / or the overall quality rating is compared and the corresponding comparison result is output via a user interface ¬ .
12. Verfahren nach einem der Ansprüche 7 bis 11, bei dem die Qualitätsbewertungen der Fehlerklassen (EC) und/oder die Gesamtqualitätsbewertung in einem abrufbaren Speicher hinterlegt werden, wodurch eine Qualitätshistorie von verschiedenen Versionen von Softwarequellcodes (SQ) im Speicher gespeichert wird.12. The method according to any one of claims 7 to 11, wherein the quality assessments of the error classes (EC) and / or the overall quality rating are stored in a retrievable memory, whereby a quality history of different versions of software source code (SQ) is stored in memory.
13. Verfahren nach Anspruch 11 und 12, bei dem in der Qualitätshistorie die jeweiligen Ist-Qualitäten und Soll- Qualitäten der Versionen des Softwarequellcodes (SQ) hinterlegt werden.13. The method of claim 11 and 12, wherein in the quality history, the respective actual qualities and target qualities of the versions of the software source code (SQ) are deposited.
14. Verfahren nach einem der Ansprüche 7 bis 13, bei dem aus den Qualitätsbewertungen der Fehlerklassen (EC) Änderungsanforderungen an den Softwarequellcode (SQ) generiert werden und aus den Änderungsanforderungen Änderungsmitteilungen erstellt werden, wobei die Änderungen in einer Änderungsmittei¬ lung jeweils einer Person oder einem Personenkreis zugeordnet sind, der für die Durchführung der Änderungen in der Ände- rungsmitteilung verantwortlich ist.14. The method according to any one of claims 7 to 13, wherein the quality of the error classes (EC) change requests to the software source code (SQ) are generated and the change requests are used to create change notifications, the changes in a change notification being respectively assigned to a person or to a group of persons responsible for carrying out the changes in the change notification.
15. Verfahren nach Anspruch 14, bei dem über eine Benutzerschnittstelle Kriterien eingebbar sind, welche bei der Gene¬ rierung der Änderungsanforderungen zu berücksichtigen sind, wobei die Kriterien insbesondere angepasste Qualitätsbewer¬ tungen und/oder Prioritäten betreffend die Behebung der Fehler sind.15. The method of claim 14, wherein a user interface criteria can be input, which are to be considered in the genes ¬ turing the change requests, wherein the criteria particularly adapted quality Bewer ¬ obligations and / or priorities are the elimination of the error on.
16. Verfahren nach Anspruch 14 oder 15, bei dem die Ände- rungsmitteilungen jeweils automatisiert der Person oder dem16. The method according to claim 14 or 15, wherein the change messages each automated the person or the
Personenkreis übermittelt werden, der für die Durchführung der Änderungen in der Änderungsmitteilung verantwortlich ist.Persons responsible for implementing the changes in the notification of change.
17. Verfahren nach einem der Ansprüche 14 bis 16, bei dem die Änderungsmitteilungen jeweils Hinweise zur Durchführung der17. The method according to any one of claims 14 to 16, wherein the change messages each notes on the implementation of
Änderung und/oder eine Abschätzung des Aufwands der Änderungen enthalten.Amendment and / or an estimate of the cost of the changes.
18. Verfahren nach Anspruch 17, bei dem die Hinweise zur Durchführung der Änderungen Musterlösungen zur Änderung des Softwarequellcodes (SQ) enthalten.18. The method of claim 17, wherein the instructions for making the changes include sample solutions for changing the software source code (SQ).
19. Verfahren nach Anspruch 18, bei dem den Musterlösungen jeweils ein Aufwand zur Durchführung der jeweiligen Musterlö- sung zugeordnet ist.19. The method according to claim 18, wherein each of the model solutions is assigned an expense for carrying out the respective pattern solution.
20. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Fehlerklassen (EC) Qualitätsfehlerklassen umfassen, welche die Fehler (EC) nach Qualitätskriterien kategorisie- ren.20. Method according to one of the preceding claims, in which the error classes (EC) comprise quality error classes which categorize the errors (EC) according to quality criteria.
21. Vorrichtung zur rechnergestützten Bewertung von Softwarequellcode (SQ) , umfassend: ein Analysemittel zum Analysieren des Softwarequellcodes (SQ) unter Berücksichtigung von Parametern umfassend Codierungsregeln und/oder Codierungsmetriken, wobei durch das Analysemittel als Analyseergebnis im Softwarequellco- de (SQ) detektierte Fehler (ER) ermittelt werden;21. An apparatus for computer-aided evaluation of software source code (SQ), comprising: an analysis means for analyzing the software source code (SQ) taking into account parameters comprising coding rules and / or coding metrics, wherein errors (ER) detected by the analysis means as an analysis result in the software source code (SQ) are determined;
- ein Klassifizierungsmittel zum Klassifizieren der detek- tierten Fehler (ER) , indem die detektierten Fehler (ER) jeweils zumindest einer Klasse aus einer Mehrzahl von Fehlerklassen (EC) zugeordnet werden, wobei jeder Fehler- klasse (EC) eine über eine Benutzerschnittstelle ausgeb¬ bare Spezifikation zugeordnet ist, welche die Fehler (ER) der jeweiligen Fehlerklasse (EC) beschreibt; ein Ausgabemittel zum Ausgeben derjenigen Fehlerklassen (EC) , welchen detektierte Fehler (ER) zugeordnet sind, über eine Benutzerschnittstelle.- a classification means for classifying the detected error (ER) by the detected error (ER) are each assigned at least one class of a plurality of defect classes (EC), each fault class (EC) is a ausgeb via a user interface ¬ is associated bare specification which describes the error (ER) of the respective error class (EC); output means for outputting, via a user interface, those error classes (EC) associated with detected errors (ER).
22. Computerprogrammprodukt mit einem auf einem maschinenles¬ baren Träger gespeicherten Programmcode zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 20, wenn das Pro- gramm auf einem Rechner läuft. 22. Computer program product with a program code stored on a machine-readable carrier for executing a method according to one of claims 1 to 20, when the program runs on a computer.
EP07820578A 2006-09-29 2007-09-26 Method for the computer-assisted analysis of a software source code Ceased EP2069920A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006046203A DE102006046203A1 (en) 2006-09-29 2006-09-29 Software source code evaluating method, involves classifying detected errors, assigning errors to error class from set of error classes, and assigning specification, which specifies errors of respective error classes to each error class
PCT/EP2007/060183 WO2008040664A1 (en) 2006-09-29 2007-09-26 Method for the computer-assisted analysis of a software source code

Publications (1)

Publication Number Publication Date
EP2069920A1 true EP2069920A1 (en) 2009-06-17

Family

ID=38319988

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07820578A Ceased EP2069920A1 (en) 2006-09-29 2007-09-26 Method for the computer-assisted analysis of a software source code

Country Status (4)

Country Link
US (1) US9274924B2 (en)
EP (1) EP2069920A1 (en)
DE (1) DE102006046203A1 (en)
WO (1) WO2008040664A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108334448A (en) * 2018-01-22 2018-07-27 泰康保险集团股份有限公司 Code verification method, apparatus and equipment

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8930909B1 (en) 2007-07-13 2015-01-06 The Mathworks, Inc. Debugging using presentation layer representations of objects
US20100070949A1 (en) * 2008-09-15 2010-03-18 Infosys Technologies Limited Process and system for assessing modularity of an object-oriented program
WO2010044150A1 (en) * 2008-10-15 2010-04-22 富士通株式会社 Program change management device, program change management program, and program change management method
US8434053B2 (en) * 2008-11-26 2013-04-30 Red Hat, Inc. Package review process workflow
DE102009007509A1 (en) * 2009-02-05 2010-08-19 Siemens Aktiengesellschaft Method and device for identifying a faulty algorithm
US10152403B2 (en) * 2009-09-01 2018-12-11 Accenture Global Services Limited Assessment of software code quality based on coding violation indications
EP2354968A1 (en) 2009-12-30 2011-08-10 Tim Frey Hyperadapter and method for accessing documents in a document base
CA2734199C (en) * 2010-03-18 2017-01-03 Accenture Global Services Limited Evaluating and enforcing software design quality
US8381186B2 (en) * 2010-06-17 2013-02-19 Verizon Patent And Licensing Inc. Software training application using automated discovery of user interface controls
DE102011006215A1 (en) * 2010-11-09 2012-05-10 Siemens Aktiengesellschaft Method and device for determining a quality rating of a software code with determination of the evaluation coverage
US8621441B2 (en) * 2010-12-27 2013-12-31 Avaya Inc. System and method for software immunization based on static and dynamic analysis
US20130091423A1 (en) * 2011-10-11 2013-04-11 Siemens Aktiengesellschaft Method and Apparatus for Checking a Structure Conformity for a Piece Of Development Documentation with at Least One Development Document
US8769501B2 (en) * 2011-12-07 2014-07-01 Siemens Aktiengesellschaft Method for analyzing changes in a software code and software analysis system
CN103793315B (en) * 2012-10-29 2018-12-21 Sap欧洲公司 Monitoring and improvement software development quality method, system and computer-readable medium
US9495281B2 (en) * 2012-11-21 2016-11-15 Hewlett Packard Enterprise Development Lp User interface coverage
US9164877B2 (en) 2013-06-21 2015-10-20 Sap Se Business application inspection and modification
US9262851B2 (en) * 2014-05-27 2016-02-16 Oracle International Corporation Heat mapping of defects in software products
US9836487B2 (en) 2014-07-28 2017-12-05 Cognizant Technology Solutions India Pvt. Ltd. System and method for ensuring code quality compliance for various database management systems
US10095869B2 (en) * 2015-09-24 2018-10-09 International Business Machines Corporation Machine learning statistical methods estimating software system's security analysis assessment or audit effort, cost and processing decisions
US10831637B2 (en) 2016-04-23 2020-11-10 International Business Machines Corporation Warning data management with respect to an execution phase
US10977017B2 (en) * 2016-04-23 2021-04-13 International Business Machines Corporation Warning data management for distributed application development
CN108121656A (en) * 2016-11-30 2018-06-05 西门子公司 A kind of software evaluation method and apparatus
US10133651B2 (en) * 2016-12-19 2018-11-20 Bank Of America Corporation Software defect analysis tool
US10430315B2 (en) * 2017-10-04 2019-10-01 Blackberry Limited Classifying warning messages generated by software developer tools
US10853231B2 (en) * 2018-12-11 2020-12-01 Sap Se Detection and correction of coding errors in software development
US11010282B2 (en) 2019-01-24 2021-05-18 International Business Machines Corporation Fault detection and localization using combinatorial test design techniques while adhering to architectural restrictions
US11263116B2 (en) 2019-01-24 2022-03-01 International Business Machines Corporation Champion test case generation
US11106567B2 (en) 2019-01-24 2021-08-31 International Business Machines Corporation Combinatoric set completion through unique test case generation
US11099975B2 (en) 2019-01-24 2021-08-24 International Business Machines Corporation Test space analysis across multiple combinatoric models
US11010285B2 (en) 2019-01-24 2021-05-18 International Business Machines Corporation Fault detection and localization to generate failing test cases using combinatorial test design techniques
US11232020B2 (en) 2019-06-13 2022-01-25 International Business Machines Corporation Fault detection using breakpoint value-based fingerprints of failing regression test cases
US10970197B2 (en) 2019-06-13 2021-04-06 International Business Machines Corporation Breakpoint value-based version control
US10990510B2 (en) 2019-06-13 2021-04-27 International Business Machines Corporation Associating attribute seeds of regression test cases with breakpoint value-based fingerprints
US10963366B2 (en) 2019-06-13 2021-03-30 International Business Machines Corporation Regression test fingerprints based on breakpoint values
US11422924B2 (en) 2019-06-13 2022-08-23 International Business Machines Corporation Customizable test set selection using code flow trees
US10970195B2 (en) 2019-06-13 2021-04-06 International Business Machines Corporation Reduction of test infrastructure
US11036624B2 (en) 2019-06-13 2021-06-15 International Business Machines Corporation Self healing software utilizing regression test fingerprints
US11416222B2 (en) * 2019-08-26 2022-08-16 Red Hat, Inc. Determining validity of multipart branching literate programs
CN111651344A (en) * 2019-12-12 2020-09-11 中国电子科技集团公司第二十八研究所 Software defect detection rule grading and combination strategy method for large-scale complex information system
US11960383B2 (en) 2020-04-01 2024-04-16 Akili Interactive Labs, Inc. Systems and methods for software design control and quality assurance
US11269626B2 (en) 2020-04-23 2022-03-08 International Business Machines Corporation Quality analysis of source code
US11816479B2 (en) * 2020-06-25 2023-11-14 Jpmorgan Chase Bank, N.A. System and method for implementing a code audit tool
US11269712B1 (en) * 2020-08-26 2022-03-08 Spirent Communications, Inc. Customized categorial error handling framework for heterogeneous component-based testing in a portable automation framework
US11449414B2 (en) 2020-08-26 2022-09-20 Spirent Communications, Inc. Mapping test parameter data elements during heterogeneous component-based testing in a portable automation framework in both API mode and UI mode
US11216347B1 (en) 2020-08-26 2022-01-04 Spirent Communications, Inc. Automatically locating resources using alternative locator expressions during heterogeneous component-based testing in a portable automation framework
CN112346967B (en) * 2020-10-20 2022-03-01 四川长虹电器股份有限公司 Pc-lint cloud service system based on cloud platform, computer equipment and storage medium
US11556318B2 (en) * 2021-03-24 2023-01-17 Bank Of America Corporation Systems and methods for assisted code development

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5960196A (en) * 1996-12-18 1999-09-28 Alcatel Usa Sourcing, L.P. Software release metric reporting system and method
US5954826A (en) * 1997-09-29 1999-09-21 Sun Microsystems, Inc. Method and apparatus for analyzing data
US6167358A (en) * 1997-12-19 2000-12-26 Nowonder, Inc. System and method for remotely monitoring a plurality of computer-based systems
US6266788B1 (en) * 1998-07-01 2001-07-24 Support.Com, Inc. System and method for automatically categorizing and characterizing data derived from a computer-based system
US7657872B2 (en) * 2000-10-23 2010-02-02 Nintendo Of America Inc. Product testing and bug tracking system
US20030069869A1 (en) * 2001-10-05 2003-04-10 Jane Gronau Computer aided strategic planning systems and methods
US7124328B2 (en) * 2002-05-14 2006-10-17 Sun Microsystems, Inc. Capturing system error messages
US7213179B2 (en) * 2002-07-30 2007-05-01 Cisco Technology, Inc. Automated and embedded software reliability measurement and classification in network elements
US7810067B2 (en) * 2002-08-30 2010-10-05 Sap Aktiengesellschaft Development processes representation and management
US8225302B2 (en) * 2003-02-13 2012-07-17 Lawrence Taylor Waugh System and method for managing source code and acquiring metrics in software development
US7240332B2 (en) 2003-04-18 2007-07-03 Ounce Labs, Inc. Method and system for detecting vulnerabilities in source code
US7685570B2 (en) * 2003-06-09 2010-03-23 Microsoft Corporation Error/exception helper
US7647579B2 (en) * 2004-03-31 2010-01-12 International Business Machines Corporation Method, system and program product for detecting deviation from software development best practice resource in a code sharing system
US8401882B2 (en) * 2005-11-08 2013-03-19 International Business Machines Corporation Aligning information technology with business objectives through automated feedback control
US7752055B1 (en) * 2006-10-19 2010-07-06 Sprint Communications Company L.P. Systems and methods for determining a return on investment for software testing
US8132156B2 (en) * 2007-06-14 2012-03-06 Red Hat, Inc. Methods and systems for testing tool with comparative testing

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2008040664A1 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108334448A (en) * 2018-01-22 2018-07-27 泰康保险集团股份有限公司 Code verification method, apparatus and equipment
CN108334448B (en) * 2018-01-22 2021-07-09 泰康保险集团股份有限公司 Code verification method, device and equipment

Also Published As

Publication number Publication date
WO2008040664A1 (en) 2008-04-10
US20100023928A1 (en) 2010-01-28
US9274924B2 (en) 2016-03-01
DE102006046203A1 (en) 2007-08-30

Similar Documents

Publication Publication Date Title
EP2069920A1 (en) Method for the computer-assisted analysis of a software source code
EP0852759B1 (en) Drafting method for industrial and building systems and computer-controlled planning system for use in said method
Braun et al. Guiding requirements engineering for software-intensive embedded systems in the automotive industry: The REMsES approach
US8490054B2 (en) Software and related software tracking during software modification
DE102005042126A1 (en) Method and apparatus for automatically evaluating the quality of a software source code
US20180018209A1 (en) Method and apparatus for a computer-based generation of component fault trees
EP2414903A1 (en) Device and method for creating a process model
EP1657670A1 (en) System and method for the control of the state and progress of technical processes or a technical project
DE102010033861A1 (en) On a formal analysis based development of requirements specifications
Simmons A win-win metric based software management approach
DE102020118832B3 (en) Method for providing security-relevant data by means of a server system, server system and computer program product
Mayr-Dorn et al. ProCon: An automated process-centric quality constraints checking framework
Langenfeld Formalisation and analysis of system requirements
DE102017212612A1 (en) Method for automatically generating tests for the software of a vehicle
Spiewak et al. Apply the Fundamentals of Quality in Software Construction to Reduce Costs and Prevent Defects.
EP2230609A2 (en) Method of providing requirements specifications for power station process control systems
WO2012013203A1 (en) System and method for distributing and exchanging elements for planning and/or for operating automation operating equipment
DE102021004346A1 (en) Procedure for building and maintaining a vehicle type library
de Amorim Model-based systems engineering maturity improvement in industry.
EP2093663A1 (en) Engineering system for developing a project and method
Vo et al. Uncertainty Research Lab Summer 2022: Data Science for Engineers
Mattsson Automatic enforcement of architectural design rules
Shigyo et al. Support Awareness of Anomaly in Coding Behavior using Code Revision Data
Hansert et al. Towards Maintainable Resilient Production Systems
Seifer et al. Understanding the Purpose of Source-Code Scopes Based on API Classifications

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090218

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090728

R17C First examination report despatched (corrected)

Effective date: 20091130

R17C First examination report despatched (corrected)

Effective date: 20090728

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170619