DE112020004468T5

DE112020004468T5 - Verfahren für automatisierte codeprüferempfehlung

Info

Publication number: DE112020004468T5
Application number: DE112020004468.8T
Authority: DE
Inventors: Jianwu XU; Ding Li; Wei Cheng; Haifeng Chen
Original assignee: NEC Laboratories America Inc
Current assignee: NEC Laboratories America Inc
Priority date: 2019-09-20
Filing date: 2020-09-11
Publication date: 2022-06-30
Also published as: JP2022544173A; US20210089992A1; WO2021055239A1

Abstract

Es wird ein Verfahren zum automatischen Empfehlen eines Prüfers für vorgelegte Codes präsentiert. Das Verfahren enthält, in einer Lernphase, ein Verwenden (801) eines Agenten künstlicher Intelligenz zum Lernen einer zugrundeliegenden und kontextuellen Struktur von Codebereichen, ein Abbilden (803) der Codebereiche in eine verteilte Darstellung, um Codebereichsdarstellungen zu definieren, in einer Empfehlungsphase, ein Verwenden (805) des Agenten künstlicher Intelligenz, um eine Rangliste von empfohlenen Prüfern für jede gegebene vorgelegte Codeüberprüfungsanforderung zu erstellen, und ein Ausgeben (807) der Rangliste von empfohlenen Prüfern zu einer Visualisierungsvorrichtung.

Description

INFORMATION ÜBER ZUGEHÖRIGE ANMELDUNGEN
Diese Anmeldung beansprucht die Priorität der vorläufigen Anmeldung Nr. 62/903,004 , eingereicht am 20. September 2019, und der US-Patentanmeldung Nr. 17/016,709 , eingereicht am 10. September 2020, die jeweils hierin durch Bezugnahme hierin in ihrer Gesamtheit enthalten sind.
HINTERGRUND
Technisches Gebiet
Die vorliegende Erfindung betrifft Code-Review bzw. eine Codeüberprüfung und insbesondere Verfahren und Systeme zum automatischen Empfehlen eines Prüfers bzw. Reviewers für vorgelegte zu prüfende Codes.
Beschreibung der zugehörigen Standes der Technik
Ein moderner Softwareentwicklungslebenszyklus (SDLC) enthält mehrere Phasen, das heißt, Anforderungssammlung und -analyse, Architekturentwurfsanalyse, Quellcodeimplementierung, verschiedene Arten eines Testens, Produkt-/Lösungs-Entwicklung und Wartung und Kundenunterstützung. Die Phase einer Quellcodeimplementierung ist dort, wo Ideen und Entwürfe im Format von Computerprogrammiersprachen realisiert werden. Diese Phase wird normalerweise von einem Team von zusammenarbeitenden Software-Ingenieuren durchgeführt. Diese Phase enthält mehrere Runden von Codeprogrammierung und Codeüberprüfung bzw. Code-Review. Es gibt mehrere Zwecke für den Codeüberprüfungsprozess. Ein erster Zweck besteht darin, die Richtigkeit zu prüfen, die vom ursprünglichen Autor übersehen werden kann. Der zweite Zweck besteht in der Code-Wartbarkeit, die die Codes für den Standard einer Organisation bestätigt. Dies ist wichtig, da während der späten Phase der Wartung und einer Kundenunterstützung in SDLC die verantwortliche Partei nicht den ursprünglichen Autoren des Quellcodes entsprechen kann. Daher ist es für den Quellcode vorteilhaft, im Standardformat gemäß der Anforderung der Organisation zu sein, so dass ein Codebetreuer alle nachfolgenden Unterstützungsangelegenheiten schnell handhaben kann.
ZUSAMMENFASSUNG
Es wird ein computerimplementiertes Verfahren zum automatischen Empfehlen eines Prüfers für vorgelegte bzw. übermittelte Codes präsentiert. Das Verfahren enthält, in einer Lernphase, ein Verwenden eines Agenten künstlicher Intelligenz zum Lernen einer zugrundeliegenden und kontextuellen Struktur von Codebereichen, ein Abbilden der Codebereiche in eine verteilte Darstellung, um Codebereichsdarstellungen zu definieren, in einer Empfehlungsphase, ein Verwenden des Agenten künstlicher Intelligenz, um eine Rangliste von empfohlenen Prüfern für irgendeine gegebene vorgelegte Codeüberprüfungsanforderung zu erstellen, und ein Ausgeben der Rangliste von empfohlenen Prüfern zu einer Visualisierungsvorrichtung.
Es wird ein nicht transitorisches bzw. nichtflüchtiges computerlesbares Speichermedium präsentiert, das ein computerlesbares Programm umfasst, zum automatischen Empfehlen eines Prüfers für vorgelegte bzw. übermittelte Codes, wobei das computerlesbare Programm dann, wenn es auf einem Computer ausgeführt wird, veranlasst, dass der Computer die folgenden Schritte durchführt: in einer Lernphase Verwenden eines Agenten künstlicher Intelligenz zum Lernen einer zugrundeliegenden und kontextuellen Struktur von Codebereichen, Abbilden der Codebereiche in eine verteilte Darstellung, um Codebereichsdarstellungen zu definieren, in einer Empfehlungsphase Verwenden des Agenten künstlicher Intelligenz, um eine Rangliste von empfohlenen Prüfern für irgendeine gegebene vorgelegte Codeüberprüfungsanforderung zu erstellen, und Ausgeben der Rangliste von empfohlenen Prüfern zu einer Visualisierungsvorrichtung.
Es wird ein System zum automatischen Empfehlen eines Prüfers für vorgelegte bzw. übermittelte Codes präsentiert. Das System enthält einen Speicher und einen oder mehrere Prozessoren in Kommunikation mit dem Speicher, konfiguriert, um in einer Lernphase einen Agenten künstlicher Intelligenz zum Lernen einer zugrundeliegenden und kontextuellen Struktur von Codebereichen zu verwenden, die Codebereiche in eine verteilte Darstellung abzubilden, um Codebereichsdarstellungen zu definieren, in einer Empfehlungsphase den Agenten künstlicher Intelligenz zu verwenden, um eine Rangliste von empfohlenen Prüfern für irgendeine gegebene vorgelegte Codeüberprüfungsanforderung zu erstellen, und die Rangliste von empfohlenen Prüfern zu einer Visualisierungsvorrichtung auszugeben.
Diese und weitere Merkmale und Vorteile werden aus der folgenden detaillierten Beschreibung von illustrativen Ausführungsformen davon offensichtlich werden, die im Zusammenhang mit den beigefügten Zeichnungen zu lesen ist.
Figurenliste
Die Offenbarung wird Details in der folgenden Beschreibung bevorzugter Ausführungsformen unter Bezugnahme auf die folgenden Figuren bereitstellen, wobei:

1 ein Block-/Ablaufdiagramm eines beispielhaften Softwareentwicklungslebenszyklus (SDLC) gemäß Ausführungsformen der vorliegenden Erfindung ist;
2 ein Block-/Ablaufdiagramm beispielhafter Softwareimplementierungsstufen gemäß Ausführungsformen der vorliegenden Erfindung ist;
3 ein Block-/Ablaufdiagramm beispielhafter Codeüberprüfungs- bzw. Code-Review-Stufen gemäß Ausführungsformen der vorliegenden Erfindung ist;
4 ein Block-/Ablaufdiagramm beispielhafter Komponenten zum Auswählen eines Prüfers gemäß Ausführungsformen der vorliegenden Erfindung ist;
5 ein Block-/Ablaufdiagramm beispielhafter Komponenten der Codebereichsdarstellung gemäß Ausführungsformen der vorliegenden Erfindung ist;
6 ein Beispiel eines Codebereichs und entsprechende Codezeilenvorlagen gemäß Ausführungsformen der vorliegenden Erfindung darstellt;
7 ein Block-/Ablaufdiagramm eines beispielhaften Verarbeitungssystems zum automatischen Empfehlen eines Prüfers bzw. Gutachters für vorgelegte Codes gemäß Ausführungsformen der vorliegenden Erfindung ist;
8 ein Block-/Ablaufdiagramm eines beispielhaften Verfahrens zum automatischen Empfehlen eines Prüfers bzw. Gutachters für vorgelegte Codes gemäß Ausführungsformen der vorliegenden Erfindung ist;
9 ein Block-/Ablaufdiagramm von bei einem beispielhaften Verfahren zum automatischen Empfehlen eines Prüfers für vorgelegte Codes verwendeten Gleichungen gemäß Ausführungsformen der vorliegenden Erfindung ist; und
10 ist ein Block-/Ablaufdiagramm einer praktischen Anwendung zum automatischen Empfehlen eines Prüfers für vorgelegte Codes gemäß Ausführungsformen der vorliegenden Erfindung ist.

DETAILLIERTE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
Die Code-Review-Phase bzw. Codeüberprüfungsphase beginnt dann, wenn der ursprüngliche Entwickler einen Satz von zu überprüfendem Quellcode vorbereitet. Der Satz von Quellcode kann mehrere Quellcode-Dateien enthalten oder nur mehrere Methoden oder Funktionen oder einige Fehlerbehebungen etc. Dann sendet der Codeautor die Überprüfungsanforderung zum beabsichtigten Überprüfer. Der Überprüfer bzw. Prüfer kann ein leitender Architekt oder Entwickler sein, der mit dem Satz von zu überprüfendem Quellcode vertraut ist. Dann arbeiten der Antragsteller und der Prüfer zusammen, um mehrere Runden von Überprüfung und Verbesserung zu durchlaufen. Schließlich wird, wenn der Prozess einmal endet, der verbesserte und korrigierte Quellcode zur Aufbewahrung in ein über ein Versionskontrollsystem gehostetes gemeinsames Code-Repository gegeben. Das Versionskontrollsystem kann das Speichern, Abrufen, Protokollieren und andere Entwicklungsprozesse automatisieren. Das Versionskontrollsystem kann z.B. Git, Concurrent Versions System (CVS) und andere kommerzielle oder Open-Source-Software enthalten. Git ist ein kostenloses und Open-Source-verteiltes Versionskontrollsystem, das entwickelt ist, um alles von kleinen bis zu sehr großen Projekten mit Geschwindigkeit und Effizienz zu behandeln bzw. zu erledigen. CVS ist ein kostenloses Client-Server-Überarbeitungskontrollsystem bzw. Versionskontrollsystem auf dem Gebiet von Softwareentwicklung. Ein Versionskontrollsystem verfolgt die gesamte Arbeit und alle Änderungen in einer Gruppe von Dateien und lässt zu, dass mehrere Entwickler zusammenarbeiten.
Eine der wichtigsten Herausforderungen beim Codeüberprüfungsprozess besteht darin, wie die richtige Person zur Überprüfung der Quellcodes auszuwählen ist. Da es für eine große Organisation mehrere Teams geben kann, die zusammen an demselben Produkt oder derselben Lösung arbeiten, können Codes, die von einem Entwickler aus einem Team geschrieben sind, in Beziehung stehen mit denjenigen, für die ein anderes Team der Autor ist. Wenn der Codeprüfer immer aus demselben Team ausgewählt wird, dann kann es sein, dass der Prüfer nicht die vollständige Information bekommt. Andererseits kann es dann, wenn der Codeprüfer aus Mitgliedern von nicht relevanten Teams ausgewählt wird, sein, dass der Prüfer nicht über das relevante Wissen verfügt, um die korrekteste Meinung bereitzustellen. Daher ist es erforderlich, dass der Prüfer ein ausgewogenes Wissen über die Codes verfügt, um die besten Ergebnisse anzubieten.
Herkömmlicherweise basiert die Auswahl des Prüfers auf dem Dienstalter von Teammitgliedern. Normalerweise wird ein Entwicklungs- bzw. Designarchitekt ausgewählt, um die Codes von Junior-Entwicklern zu überprüfen, da der Softwarearchitekt unterschiedliche Komponenten der Software versteht. Es wäre jedoch kostspielig, wenn der hochbezahlte Softwarearchitekt immer ausgewählt wird, um die Codes von Junior-Programmierern zu überprüfen. Es ist auch eine auf Relevanz basierende Auswahl basierend auf den Bewertungen bezüglich einer Rangfolge von einer Historie jedes einzelnen Codeprüfers vorgeschlagen worden. Dann wird ein top-bewerteter Prüfer basierend auf der Review- bzw. Überprüfungs-Historie eines Individuums ausgewählt, die für die Codes relevant ist. Dieser Ansatz neigt jedoch dazu, Prüfer auszuwählen, die eine hohe Anzahl von Überprüfungen bzw. Reviews haben, kann die Qualität der Überprüfungen ignorieren.
Die beispielhaften Ausführungsformen der vorliegenden Erfindung führen ein Verfahren ein, das in der Lage ist, den Prüfer für die vorgelegten zu prüfenden Codes automatisch zu empfehlen. Die Empfehlung basiert auf der Überprüfungs- bzw. Review-Historie, dem Codierungsstil und der Verpflichtungs-Historie, und der Beschäftigungsposition jedes einzelnen Prüfers quer durch unterschiedliche Entwicklungsteams. Diese Gruppe von mehreren Informationsquellen wird verwendet, um das Modell so zu trainieren, dass das Modell in der Lage ist, den relevantesten Prüfer angesichts des Satzes von vorgelegten Codeüberprüfungsanforderungen zu finden. Eine Einbettung von tiefem Lernen wird verwendet, um den Code für eine nachfolgende Ähnlichkeitsberechnung darzustellen. Diese Darstellung ist in der Lage, die Kontextinformation der Codes innerhalb der Softwarekomponente zu extrahieren.
1 Präsentiert die Komponenten in einem herkömmlichen Softwareentwicklungslebenszyklus (SDLC (= Software Development Life Cycle)). Der SDLC beginnt mit der Softwareanforderungsanalyse und einer Planung für die Entwicklung 101. Die Anforderungen ergeben sich aus dem Geschäftszweck der schließlichen Lösung oder des schließlichen Produkts. Dann geht der SDLC weiter zu dem Analyseentwurf 102, der Softwarearchitekturdesign, Programmiersprachenauswahl, Softwareentwicklungsumgebungsauswahl und vieles andere enthält, aber nichtdarauf beschränkt ist. Wenn der Entwurf bzw. das Design 102 einmal fertig ist, ist die nächste Phase bzw. Stufe einer Implementierung 103, die das Softwareprodukt in einer Folge von Programmiersprachen materialisiert. Wenn die Implementierung 103 einmal durchgeführt ist, wird ein Testen der Software 104 angewendet, um die Qualität und Richtigkeit des Produkts sicherzustellen. Wenn das Produkt das Testen besteht, wird das Produkt bereitgestellt und zu einem oder mehreren Kundenstandorten ausgeliefert 105. Laufende Wartung und Unterstützung bzw. Support 106 werden den Kunden zur kontinuierlichen Verbesserung und Zufriedenstellung zur Verfügung gestellt.
Die Komponente Softwareimplementierung 103 in SDLC enthält mehrere Phasen bzw. Stufen, wie es in 2 gezeigt ist. Die Softwareimplementierung 103 beginnt mit dem Architekturentwurf bzw. -design 201, der bzw. das das Fundament für die Software legt. Der Architekturentwurf 201 wird normalerweise von dem leitenden Architekten bzw. Seniorarchitekten entworfen, der den Arbeitsablauf, das Dienstmodell und die Verbindung von jeder unterschiedlichen Anwendungsprogrammierschnittstelle (API) etc. bestimmt. Wenn die Entwurfsphase 201 einmal beendet ist, bewegt sich der Prozess zum Quellcodeimplementierungsblock 202. Jedes Team wird mit einer anderen Softwarekomponente beauftragt und realisiert solche Softwarekomponenten in einer gewählten Programmiersprache. Die Komponente 203 startet den Codeüberprüfungsprozess für jede Softwarekomponente, um die Wartbarkeit des Codes sicherzustellen und Codierungsfehler zu reduzieren. Wenn die Softwarekomponente den Codeüberprüfungsprozess besteht, checkt sie in die Codebasis 204 ein und bewegt sich zur nächsten Stufe im SDLC.
3 stellt die sequenziellen Schritte innerhalb der Code-Review-Komponente bzw. Codeüberprüfungskomponente 203 dar. Der ursprüngliche Softwareentwickler bereitet einen Satz bzw. eine Gruppe von zu überprüfenden Codes vor 301. Dies kann mehrere Quellcodedateien, Konfigurationsdateien, Verpflichtungs-Historie etc. enthalten. Dann legt der Entwickler die Anforderung vor 302, und zwar der Teamzusammenarbeitsumgebung wie beispielsweise Visual Studio Team Foundation von Microsoft oder einer anderen Projektmanagementsoftware. Der Entwickler kann einen Prüfer aus der Zusammenarbeitsumgebung manuell auswählen oder er kann basierend auf einem bestimmten Kriterium automatisch ausgewählt werden 303. Der ausgewählte Prüfer überprüft die vorgelegten Codes und startet die Korrekturen, Kommentare oder Fragen 304. Dieses Feedback wird dem ursprünglichen Antragsteller zur Verfügung gestellt, und der Antragsteller modifiziert und verbessert die ursprünglichen Quellcodes basierend auf den Kommentaren des Prüfers bzw. Überprüfers. Dann beginnt diese Prozedur von vorn, bis alle Modifikationen abgeschlossen sind und sich beide Parteien auf die endgültige Version geeinigt haben.
4 stellt den gesamten Arbeitsablauf der vorliegenden Erfindung dar, der den relevantesten Prüfer anhand eines Satzes von eingereichten Codes automatisch auswählt. Der Arbeitsablauf enthält zwei Phasen, die Lernphase und die Empfehlungsphase. Die Lernphase ist die Phase, in der ein Agent künstlicher Intelligenz (KI) die zugrundeliegende und kontextuelle Struktur von Codebereichen lernt und die Codebereiche in einer verteilten Darstellung abbildet, so dass sie für die nachfolgende Ähnlichkeitssuche verwendet werden. In der Empfehlungsphase erstellt der KI-Agent eine Rangliste von empfohlenen Prüfern für eine gegebene vorgelegte Codeüberprüfungsanforderung.
In Bezug auf den Codeüberprüfungsverlauf 401 ist eine der Eingaben für die Komponente 403 der Codeüberprüfungsverlauf 401. Der Codeüberprüfungsverlauf bzw. die Codeüberprüfungshistorie 401 enthält Metadateninformation, wie beispielsweise welcher Prüfer einen bestimmten Teilbereich der Codebereiche überprüft, welche Menge an Quellcodes von einem bestimmten Überprüfer überprüft wird, wie viele Feedback-Runden und Verbesserungen für jede Überprüfung stattgefunden habe, etc. Diese Information wird von einer Komponente 403 verwendet, um die Darstellung für jeden Überprüfer zu erstellen.
In Bezug auf die Code-Verpflichtungs-Historie der Entwickler 402 wird dieser Satz von Information verwendet, um eigenes Fachwissen der Prüfer in unterschiedlichen Softwaremodulen darzustellen. Einige Prüfer können Datenbankmodule programmieren und gleichzeitig Quellcodes aus Frontend-Anwendungen überprüfen. Da es eine Verbindung zwischen der Backend-Datenbank und den Frontend-Anwendungen gibt, hat dieser spezielle Prüfer die einzigartige Position, beide Quellcodes zu verstehen, und kann der ideale Kandidat für die Überprüfung der Frontend-Quellcodes sein. Die Code-Verpflichtungs-Historie bzw. Code-Commit-Historie enthält Metainformation, wie beispielsweise welche Softwaremodule oder -komponenten von einem bestimmten Prüfer geschrieben wurden und deren Revisionshistorie, Häufigkeit und zeitliche Information zu jeder Verpflichtung etc. Diese Information wird extrahiert und für die Erzeugung des Fachwissens bzw. der Expertise und des Wissensstands jedes Entwicklers verwendet.
In Bezug auf die Codebereichsdarstellung 403 ist es erforderlich, dass die Eingaben 401 und 403 in eine kompakte Darstellung konvertiert bzw. umgewandelt werden, so dass jeder der unterschiedlichen Codebereiche verglichen werden kann.
5 präsentiert die unterschiedlichen Komponenten innerhalb von 403.
In Bezug auf das Erzeugen eines globalen Codezeilenvorlagenwörterbuchs 501 besteht der erste Schritt darin, ein globales Wörterbuch für jede Codezeile zu erstellen, um unterschiedliche Codebereiche zu vergleichen, so dass Aktivitäten der Codeprüfer verglichen und normalisiert werden können. Codezeile steht für jede Zeile eines Quellcodes. Diese Komponente nimmt die Gesamtheit des Code-Repositorys, um die vollständige Codezeilenvorlage zu lernen. Die Vorlage ist als das erzeugende Muster jeder Quellcodezeile definiert. 6 stellt ein Beispiel des ursprünglichen Quellcodes 601 und seiner entsprechenden Codezeilenvorlage 603 dar. Diese Komponente erzeugt automatisch die Codezeilenvorlage. Jeder Codezeilenvorlage ist eine eindeutige ID zugewiesen.
In Bezug auf das Abbilden jeder Codezeile in dem Bereich zum globalen Wörterbuch 502 bildet 502 dann, wenn einmal das globale Codezeilenvorlagenwörterbuch erzeugt ist, jede Codezeile in seine eigene eindeutige Vorlagen-ID ab. Daher ist jede Quellcodezeile in eine vergleichbare Basis transformiert worden, so dass ihre Ähnlichkeit verglichen werden kann.
In Bezug auf die Berechnung des TFIDF-Vektors für jeden Codebereich 503 wird jeder Codebereich in einen Vektor transformiert, wobei das Element die Berechnung des TFIDF-(Term-Frequency Inverse Document Frequency (= Vorkommenshäufigkeit - inverse Dokumenthäufigkeit))Werts jeder Codezeilenvorlage ist.
TFIDF ist definiert als:
Für jede Codezeilenvorlage i wird sie wie folgt berechnet:
$TF - {IDF}_{I} = P_{i} \cdot I D F_{i}$
Dabei ist P_i die Häufigkeit der Codezeilenvorlage i im gesamten Codebereich und ist IDF_i die inverse Dokumenthäufigkeit für die Codezeilenvorlage i.
Sie ist definiert als:
${IDF}_{i} = log \frac{Gesamtanzahl von Codebereichen}{Anzahl von Codebereichen mit Vorlage i darin}$
Bezüglich der Berechnung der Codezeilensequenz für jeden Codebereich 504 verwenden die beispielhaften Ausführungsformen der vorliegenden Erfindung zwei Arten von Ähnlichkeitsmerkmalen. Eine wird in 503 als TDIDF-Funktion berechnet, die die Codezeilenvorlagenverteilungen charakterisiert, und die andere sind die Codezeilenvorlagensequenzen. Die Codezeilenvorlagensequenz spezifiziert den Codeübergang. Die extrahierte automatisierte Sequenz wird in 504 angewendet, um die Codezeilenvorlagen-Ablaufreihenfolge zu erzeugen.
Bezüglich der Codebereichs-Ähnlichkeitserzeugung 404 werden zwei Sätze bzw. Gruppen von Ähnlichkeitsmaßen erzeugt. Das erste Ähnlichkeitsmaß wird verwendet, um den Kosinusabstand zwischen zwei beliebigen TFIDF-Vektoren zu berechnen. Dieses Ähnlichkeitsmaß berechnet die Inhaltsähnlichkeit basierend auf den Codezeilenvorlagen. Die beispielhaften Ausführungsformen der vorliegenden Erfindung verwenden einen Kosinusabstand, um die Ähnlichkeit zwischen zwei TFIDF-Vektoren zu messen.
Angesichts von zwei TFIDF-Vektoren, A und B, wird die Kosinusähnlichkeit, cos(θ), unter Verwendung eines Punktprodukts und einer Größe wie folgt dargestellt: $cos (θ) = \frac{A \cdot B}{‖ A ‖ ‖ B ‖} = \frac{\sum_{i = 1}^{n} A_{i} B_{i}}{\sqrt{\sum_{i = 1}^{n} A_{i}^{2}} \sqrt{\sum_{i = 1}^{n} B_{i}^{2}}}$
Wobei jedes A_i und B_i die TFIDF-Werte innerhalb eines bestimmten Codebereichs sind. Da TFIDFs positive Zahlen sind, liegt der Wert von cos(θ) im Bereich zwischen 0 und 1, wobei 0 am wenigsten ähnlich ist und 1 identisch ist.
Das zweite Ähnlichkeitsmaß basiert auf der Codezeilenvorlagensequenzähnlichkeit. Das zweite Ähnlichkeitsmaß misst die Strukturähnlichkeit zwischen zwei beliebigen Codebereichen. Die Sequenzähnlichkeit basiert auf der Methode des Smith-Waterman-Algorithmus, der einen Abstands- bzw. Entfernungswert erzeugt, um die Ähnlichkeit der Sequenzen zu beschreiben.
Bezüglich zu prüfender vorgelegter Codes 405 ist dies der Satz bzw. die Gruppe von Quellcodedateien, die vom Entwickler vorgelegt sind, der die Codeüberprüfung bzw. Code-Review anfordert. Der Anforderer organisiert die Quellcodedateien und überreicht sie zur Teamzusammenarbeitsumgebung.
Bezüglich des Ähnlichkeitsvergleichs 406 durchlaufen die zu überprüfenden Quellcodedateien die Komponente 403, um die verteilte Darstellung basierend auf Codezeilenvorlagen und Struktursequenz zu erzeugen. Der Ähnlichkeitsvergleich 406 erzeugt einen TFIDF-Vektor für die Codedateien 405 und die Codevorlagensequenz. Es gibt mehrere TFIDF-Vektoren, die mit einem jeweiligen Prüfer assoziiert sind, da sie mehrere Quellcodes festgeschrieben bzw. verpflichtet und unterschiedliche Softwaremodule überprüft haben. Daher wird der TFIDF-Vektor für den zu überprüfenden Quellcode 405 mit jedem der TFIDF-Vektoren verglichen, die mit jedem Prüfer assoziiert sind, und zwar basierend auf dem in 404 definierten Kosinusabstand. Die endgültige Ähnlichkeit basierend auf TFIDF wird für jeden Prüfer in einen normalisierten Wert aggregiert. Dieselbe Prozedur wird für das Ähnlichkeitsmaß basierend auf der Codezeilenvorlagensequenz durchgeführt und in einen endgültigen normalisierten Wert aggregiert. Das gesamte Ähnlichkeitsmaß zwischen dem zu überprüfenden Codebereich und jedem Entwickler ist der Durchschnitt der zwei vorgenannten Ähnlichkeitsentfernungen bzw. -abstände.
Bezüglich des Organisationsplans des Entwicklers 407 beschreibt, während die Quellcodeverpflichtungs-Historie 402 und die manuellen Überprüfungsaktivitäten 401 die Expertise, das Wissen und die Erfahrung des Entwicklers darstellen, die Beschäftigungsposition des Entwicklers innerhalb des Unternehmens die Seniorität. Da ein idealer Prüferkandidat sowohl über das richtige Fachwissen als auch über eine diversifizierte Beschäftigungsposition verfügen sollte, verwenden die beispielhaften Ausführungsformen der vorliegenden Erfindung das Positionsdiagramm der Organisation, um die relevante Information zu extrahieren. Der Organisationsplan wird als Baumdiagramm dargestellt.
Die Entfernung bzw. der Abstand zwischen dem Entwickler, der die Codeüberprüfungsanforderung vorlegt, und einem beliebigen Prüferkandidaten basiert auf einer Baumpfadmetrik, die wie folgt definiert ist: $s_{l} (v_{i}, v_{j}) = \frac{1}{1 + l (v_{i}, v_{j})} = \frac{1}{1 + l (v_{i}, l c a_{i j}) + l (v_{j}, l c a_{i j})} .$
Wobei v_i und v_j zwei Entwickler darstellen, l(v_i, v_j) ein kürzester Weg zwischen zwei Entwicklern im Organisationsbaumdiagramm ist und I_caij ein niedrigster gemeinsamer Vorfahre zwischen v_i und v_j ist.
Bezüglich der Überprüfungsempfehlung 408 ist der endgültige Prüferempfehlungswert eine konvexe Kombination von 406 und 407, wie es in der folgenden Gleichung gezeigt ist:
$Q (v_{i}, v_{j}) = (1 - α) S (v_{i}, v_{j}) + α 0 (v_{i}, v_{j})$
Dabei ist S(v_i, v_j) die Ähnlichkeitsentfernung bzw. der Ähnlichkeitsabstand basierend auf dem Organisationsplan des Entwicklers von 407 und ist o(v_i, v_j) die Ähnlichkeitsentfernung bzw. der Ähnlichkeitsabstand basierend auf dem Fachwissen des Prüfers, berechnet aus 406. Basierend auf der Bewertung bzw. der Punktzahl empfiehlt 408 eine Liste von Prüfern mit hohen Q(v_i, v_j)-Werten. Der Entwickler, der die Überprüfungsanforderung vorlegt, kann einen Kandidaten aus der Liste auswählen.
7 ist ein Block-/Ablaufdiagramm eines beispielhaften Verarbeitungssystems zum automatischen Empfehlen eines Prüfers für vorgelegte Codes gemäß Ausführungsformen der vorliegenden Erfindung.
Das Verarbeitungssystem enthält wenigstens einen Prozessor oder eine Prozessorvorrichtung (CPU) 704 und eine Grafikverarbeitungseinheit (GPU) 705, die über einen Systembus 702 operativ mit anderen Komponenten gekoppelt sind. Ein Cache 706, ein Nurlesespeicher (ROM) 708, ein Direktzugriffsspeicher (RAM) 710, ein Eingabe/Ausgabe-(I/O-)Adapter 720, ein Netzwerkadapter 730, ein Benutzerschnittstellen-Adapter 740 und ein Anzeige-Adapter 750 sind operativ mit den Systembus 702 gekoppelt. Ein Einbettungsmodul/-system für tiefes Lernen 760 kann über den Bus 702 verwendet werden. Das Einbettungsmodul/-system für tiefes Lernen 760 kann eine Lernphase 772 und eine Empfehlungsphase 774 verwenden, um einen Prüfer für vorgelegte Codes automatisch zu empfehlen.
Eine Speichervorrichtung 722 ist über den I/O-Adapter 720 operativ mit dem Systembus 702 gekoppelt. Die Speichervorrichtung 722 kann eine beliebige Festplattenspeichervorrichtung (z.B. eine magnetische oder optische Festplattenspeichervorrichtung), eine magnetische Festkörpervorrichtung und so weiter sein.
Ein Transceiver 732 ist über den Netzwerkadapter 730 operativ mit dem Systembus 702 gekoppelt.
Benutzereingabevorrichtungen 742 sind durch den Benutzerschnittstellen-Adapter 740 operativ mit dem Systembus 702 gekoppelt. Die Benutzereingabevorrichtungen 742 können eine Tastatur, eine Maus, eine kleine Tastatur bzw. ein Keypad, eine Bilderfassungsvorrichtung, eine Bewegungserfassungsvorrichtung, ein Mikrofon, eine Vorrichtung, die die Funktionalität von wenigstens zwei der vorhergehenden Vorrichtungen enthält, und so weiter sein. Natürlich können auch andere Arten von Eingabevorrichtungen verwendet werden, während der Sinngehalt der vorliegenden Erfindung erhalten bleibt. Die Benutzereingabevorrichtungen 742 können dieselben Typen von Benutzereingabevorrichtungen oder unterschiedliche Arten von Benutzereingabevorrichtungen sein. Die Benutzereingabevorrichtungen 742 dienen zur Eingabe und Ausgabe von Information zu und aus dem Verarbeitungssystem.
Eine Anzeigevorrichtung 752 ist durch den Anzeigeadapter 650 operativ mit dem Systembus 702 gekoppelt.
Natürlich kann das Verarbeitungssystem auch andere Elemente (nicht gezeigt) enthalten, wie es von einem Fachmann auf dem Gebiet leicht in Betracht gezogen wird, sowie bestimmte Elemente weglassen. Zum Beispiel können verschiedene andere Eingabevorrichtungen und/oder Ausgabevorrichtungen im System enthalten sein, und zwar abhängig von der jeweiligen Implementierung desselben, wie es von einem der Fachmann auf dem Gebiet leicht verstanden wird. Zum Beispiel können verschiedene Arten von drahtlosen und/oder kabelgebundenen Eingabe- und/oder Ausgabevorrichtungen verwendet werden. Darüber hinaus können auch zusätzliche Prozessoren, Prozessorvorrichtungen, Controller bzw. Steuerungen, Speicher und so weiter in verschiedenen Konfigurationen verwendet werden, wie es von einem Fachmann auf dem Gebiet leicht eingesehen wird. Diese und andere Variationen des Verarbeitungssystems werden angesichts der hierin enthaltenen Lehren der vorliegenden Erfindung leicht von einem Fachmann auf dem Gebiet in Betracht gezogen.
8 ist ein Block-/Ablaufdiagramm eines beispielhaften Verfahrens zum automatischen Empfehlen eines Prüfers für vorgelegte Codes gemäß Ausführungsformen der vorliegenden Erfindung.
Bei einem Block 801 erfolgt, in einer Lernphase, ein Verwenden eines Agenten künstlicher Intelligenz, um eine zugrundeliegende und kontextuelle Struktur von Codebereichen zu lernen.
Bei einem Block 803 erfolgt ein Abbilden der Codebereiche in eine verteilte Darstellung, um Codebereichsdarstellungen zu definieren.
Bei einem Block 805 erfolgt, in einer Empfehlungsphase, ein Verwenden des Agenten künstlicher Intelligenz, um eine Rangliste von empfohlenen Prüfern für irgendeine gegebene vorgelegte Codeüberprüfungsanforderung zu erstellen.
Bei einem Block 807 erfolgt ein Ausgeben der Rangliste von empfohlenen Prüfern zu einer Visualisierungsvorrichtung.
9 ist ein Block-/Ablaufdiagramm von bei Verfahren zum automatischen Empfehlen eines Prüfers für vorgelegte Codes verwendeten Gleichungen gemäß Ausführungsformen der vorliegenden Erfindung.
Die Gleichungen 900 identifizieren die Vorkommenshäufigkeit - inverse Dokumenthäufigkeit (TFIDF), die Kosinusähnlichkeit, eine Baumpfadmetrik und eine endgültige Bewertung der Prüferempfehlung.
10 ist ein Block-/Ablaufdiagramm einer praktischen Anwendung zum automatischen Empfehlen eines Prüfers für vorgelegte Codes gemäß Ausführungsformen der vorliegenden Erfindung.
Eine Vielzahl von Kandidatenprüfern 1001 kann verwendet werden, um den Quellcode 1003 zu überprüfen. Ein Einbettungsmodul/-system für tiefes Lernen 760 wird verwendet, um den Quellcode 1003 für eine Ähnlichkeitsberechnung 1005 darzustellen. Diese Darstellung ist in der Lage, die Kontextinformation des Quellcodes 1003 innerhalb der Softwarekomponente zu extrahieren. Das Einbettungsmodul/-system für tiefes Lernen 760 ermöglicht die Auswahl eines Prüfers 1010 aus der Vielzahl der Kandidatenprüfer 1001 für die Überprüfung des Quellcodes 1003.
Wie sie hierin verwendet sind, können die Ausdrücke „Daten“, „Inhalt“, „Information“ und ähnliche Ausdrücke austauschbar verwendet werden, um sich auf Daten zu beziehen, die gemäß verschiedenen beispielhaften Ausführungsformen aufgenommen, gesendet, empfangen, angezeigt und/oder gespeichert werden können. Somit sollte die Verwendung von irgendwelchen solchen Ausdrücken nicht dafür genommen werden, den Sinngehalt und Schutzumfang der Offenbarung zu beschränken. Weiterhin können dort, wo hierin eine Computervorrichtung beschrieben ist, um Daten von einer anderen Computervorrichtung zu empfangen, die Daten direkt von einer anderen Computervorrichtung empfangen werden oder sie können indirekt von über eine oder mehrere dazwischenliegende bzw. vermittelnde Computervorrichtungen empfangen werden, wie zum Beispiel einen oder mehrere Server, Relais, Router, Netzwerk-Zugangspunkten, Basisstationen und/oder ähnliches. Gleichermaßen können dort, wo hierin eine Computervorrichtung beschrieben ist, um Daten zu einer anderen Computervorrichtung zu senden, die Daten direkt zu der anderen Computervorrichtung gesendet werden oder sie können indirekt über eine oder mehrere dazwischenliegende bzw. vermittelnde Computervorrichtungen gesendet werden, wie zum Beispiel einen oder mehrere Server, Relais, Router, Netzwerk-Zugangspunkten, Basisstationen und/oder ähnliches.
Um für eine Interaktion mit einem Anwender zu sorgen, können Ausführungsformen des in dieser Beschreibung beschriebenen Gegenstands auf einem Computer implementiert sein, der eine Anzeigevorrichtung, wie z.B. einen CRT-(Kathodenstrahlröhren-) oder einen LCD-(Flüssigkristallanzeige-)Monitor, zum Anzeigen von Information zu einem Anwender hat, und eine Tastatur und eine Zeigevorrichtung, wie z.B. eine Maus oder einen Trackball bzw. eine Rollkugel, durch welche der Anwender eine Eingabe zum Computer bereitstellen kann. Andere Arten von Vorrichtungen können ebenso gut verwendet werden, um für eine Interaktion mit dem Anwender zu sorgen: zum Beispiel kann eine zum Anwender gelieferte Rückmeldung irgendeine Form einer sensorischen Rückmeldung sein, wie z.B. eine visuelle Rückmeldung, eine auditorische Rückmeldung oder eine taktile Rückmeldung; und eine Eingabe vom Anwender kann in irgendeiner Form empfangen werden, einschließlich einer akustischen, sprachlichen oder taktilen Eingabe.
Wie es von einem Fachmann auf dem Gebiet eingesehen werden wird, können Aspekte der vorliegenden Erfindung als ein System, ein Verfahren oder ein Computerprogrammprodukt ausgeführt werden. Demgemäß können Aspekte der vorliegenden Erfindung die Form einer Ausführungsform gänzlich in Hardware, einer Ausführungsform gänzlich in Software (einschließlich Firmware, residenter Software, Mikrocode, etc.) oder einer Ausführungsform, die Software- und Hardware-Aspekte kombiniert, annehmen, auf die alle hierin allgemein als „Schaltung“, „Modul“, „Recheneinheit“, „Vorrichtung“ oder „System“ Bezug genommen werden kann. Weiterhin können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien mit darauf verkörpertem computerlesbaren Programmcode verkörpert ist.
Irgendeine Kombination von einem oder mehreren computerlesbaren Medien kann verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann, ist aber nicht darauf beschränkt, zum Beispiel ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine Vorrichtung oder ein Gerät sein, oder irgendeine Kombination aus den voranstehenden. Mehr spezifische Beispiele (eine nicht erschöpfende Liste) des computerlesbaren Speichermediums würden das Folgende enthalten: eine elektrische Verbindung mit einem oder mehreren Drähten, eine portierbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Nurlesespeicher (ROM), einen löschbaren programmierbaren Nurlesespeicher (EPROM oder USB-Stick), eine optische Faser bzw. Glasfaser, einen Nurlesespeicher einer portierbaren Computerdiskette (CD-ROM), eine optische Datenspeichervorrichtung, eine magnetische Datenspeichervorrichtung oder irgendeine geeignete Kombination des voranstehenden. In Zusammenhang mit diesem Dokument kann ein computerlesbares Speichermedium irgendein konkretes Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einem Gerät zur Anweisungsausführung enthalten oder speichern kann.
Ein computerlesbares Signalmedium kann ein ausgebreitetes Datensignal mit einem darin verkörperten computerlesbaren Programmcode enthalten, wie zum Beispiel im Basisband oder als Teil einer Trägerwelle. Ein solches ausgebreitetes Signal kann irgendeine Vielfalt von Formen annehmen, einschließlich, aber nicht darauf beschränkt, elektromagnetisch, optisch oder irgendeine geeignete Kombination davon. Ein computerlesbares Signalmedium kann irgendein computerlesbares Medium sein, das kein computerlesbares Speichermedium ist und das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einem Gerät zur Anweisungsausführung kommunizieren, ausbreiten oder transportieren kann.
Ein auf einem computerlesbaren Medium verkörperter Programmcode kann unter Verwendung von irgendeinem geeigneten Medium übertragen werden, einschließlich, aber nicht darauf beschränkt, drahtlos, drahtgebunden, Glasfaserkabel, RF, etc., oder irgendeiner geeigneten Kombination des voranstehenden.
Ein Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorliegenden Erfindung kann in irgendeiner Kombination von einer oder mehreren Programmiersprachen geschrieben sein, einschließlich einer objektorientierten Programmiersprache, wie beispielsweise Java, Smalltalk, C++ oder ähnlichem, und herkömmlicher verfahrensorientierter Programmiersprachen, wie beispielsweise der C++-Programmiersprache oder ähnlichen Programmiersprachen.
Der Programmcode kann gänzlich auf dem Computer eines Anwenders, teilweise auf dem Computer eines Anwenders, als ein alleinstehendes Software-Paket, teilweise auf dem Computer eines Anwenders und teilweise auf einem entfernten Computer oder gänzlich auf dem entfernten Computer oder Server ausführen. Beim letzteren Szenario kann der entfernte Computer mit dem Computer eines Anwenders durch irgendeinen Typ von Netzwerk verbunden sein, einschließlich eines lokalen Netzes (LAN) oder eines Weitverkehrsnetzes (WAN), oder die Verbindung kann zu einem externen Computer (zum Beispiel durch das Internet unter Verwendung eines Internet-Dienstanbieters) ausgeführt werden.
Aspekte der vorliegenden Erfindung werden nachstehend unter Bezugnahme auf Ablaufdiagrammdarstellungen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der vorliegenden Erfindung beschrieben. Es wird verstanden werden, dass jeder Block der Ablaufdiagrammdarstellungen und/oder der Blockdiagramme und Kombinationen von Blöcken in den Ablaufdiagrammdarstellungen und/oder den Blockdiagrammen durch Computerprogrammanweisungen implementiert werden können. Diese Computerprogrammanweisungen können einem Prozessor eines allgemeinen Computers, eines Computers für spezielle Zwecke oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Anweisungen, die über den Prozessor des Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung ausführen, Mittel zum Implementieren der Funktionen/Handlungen erzeugen, die in dem Ablaufdiagramm und/oder den Blockdiagrammblöcken oder Blöcken oder Modulen spezifiziert sind.
Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert werden, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Vorrichtungen bzw. Geräte anleiten kann, auf eine bestimmte Weise zu funktionieren, so dass die im dem computerlesbaren Medium gespeicherten Anweisungen einen Herstellungsgegenstand bzw. ein Erzeugnis erzeugen bzw. produzieren, einschließlich Anweisungen, die die Funktion/Handlung implementieren, die im Ablaufdiagramm und/oder Blockdiagrammblock oder Blöcken oder Modulen spezifiziert ist.
Die Computerprogrammanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Vorrichtungen bzw. Geräte geladen werden, um zu veranlassen, dass eine Reihe von Operationsschritten auf dem Computer, einer anderen programmierbaren Vorrichtung oder anderen Vorrichtungen bzw. Geräten durchgeführt wird, um einen computerimplementierten Prozess zu erzeugen bzw. zu produzieren, so dass die Anweisungen, die auf dem Computer oder einer anderen programmierbaren Vorrichtung ausführen, Prozesse zum Implementieren des Funktionen/Handlungen bereitstellen, die in dem Ablaufdiagramm und/oder dem Blockdiagrammblock oder den Blöcken oder Modulen spezifiziert sind.
Es ist einzusehen, dass beabsichtigt ist, das der Ausdruck „Prozessor“, wie er hierin verwendet wird, irgendeine Verarbeitungsvorrichtung enthält, wie zum Beispiel eine, welche eine CPU (zentrale Verarbeitungseinheit) und/oder eine andere Verarbeitungsschaltung enthält. Es ist auch zu verstehen, dass sich der Ausdruck „Prozessor“ auf mehr als eine Verarbeitungsvorrichtung beziehen kann und dass verschiedene Elemente, die mit einer Verarbeitungsvorrichtung assoziiert sind, durch andere Verarbeitungsvorrichtungen gemeinsam genutzt werden können.
Es ist beabsichtigt, dass der Ausdruck „Speicher“, wie er hierin verwendet ist, einen Speicher enthält, der mit einem Prozessor oder einer CPU assoziiert ist, wie zum Beispiel einen RAM, einen ROM, eine feste Speichervorrichtung (z.B. eine Festplatte), eine entfernbare Speichervorrichtung (z.B. eine Diskette), einen USB-Stick, etc.. Ein solcher Speicher kann als ein computerlesbares Speichermedium angesehen werden.
Zusätzlich ist beabsichtigt, dass die Formulierung „Eingabe/AusgabeVorrichtungen“ oder „I/O-Vorrichtungen“, wie sie hierin verwendet ist, zum Beispiel eine oder mehrere Eingabevorrichtungen (z.B. Tastatur, Maus, Scanner, etc.) zum Eingeben von Daten zur Verarbeitungseinheit und/oder eine oder mehrere Ausgabevorrichtungen (z.B. Lautsprecher, Anzeige, Drucker etc.) zum Präsentieren von Ergebnissen, assoziiert mit der Verarbeitungseinheit, enthält.
Das Voranstehende ist in jederlei Hinsicht als illustrativ und beispielhaft, aber nicht als beschränkend, zu verstehen, und der Schutzumfang der hierin offenbarten Erfindung ist nicht aus der detaillierten Beschreibung zu bestimmen, sondern eher aus den Ansprüchen, wie sie gemäß der vollständigen Breite interpretiert werden, die durch das Patentrecht zugelassen ist. Es ist zu verstehen, dass die hierin gezeigten und beschriebenen Ausführungsformen nur illustrativ für die Prinzipien der vorliegenden Erfindung sind und dass Fachleute auf dem Gebiet verschiedene Modifikationen implementieren können, ohne von dem Schutzumfang und dem Sinngehalt der Erfindung abzuweichen. Fachleute auf dem Gebiet könnten verschiedene andere Merkmalskombinationen implementieren, ohne von dem Schutzumfang und dem Sinngehalt der Erfindung abzuweichen. Sind somit die Aspekte der Erfindung mit den Details und der Besonderheit, die durch das Patentrecht erforderlich sind, beschrieben worden, ist das, was beansprucht ist und durch das Patent geschützt erwünscht ist, in den beigefügten Ansprüchen dargelegt.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62/903004 [0001]
US 17/016709 [0001]

Claims

Computerimplementiertes Verfahren, das auf einem Prozessor ausgeführt wird, zum automatischen Empfehlen eines Prüfer für vorgelegte Codes, wobei das Verfahren folgendes umfasst: Verwenden (801), in einer Lernphase, eines Agenten künstlicher Intelligenz zum Lernen einer zugrundeliegenden und kontextuellen Struktur von Codebereichen; Abbilden (803) der Codebereiche in eine verteilte Darstellung, um Codebereichsdarstellungen zu definieren; Verwenden (805), in einer Empfehlungsphase, des Agenten künstlicher Intelligenz, um eine Rangliste von empfohlenen Prüfern für eine gegebene vorgelegte Codeüberprüfungsanforderung zu erstellen; und Ausgeben (807) der Rangliste von empfohlenen Prüfern zu einer Visualisierungsvorrichtung.
Verfahren nach Anspruch 1, wobei die Rangliste von empfohlenen Prüfern auf einer Codeüberprüfungshistorie, einem Codierungsstil, einer Verpflichtungs-Historie und einer Beschäftigungsposition jedes Kandidatenprüfers basiert.
Verfahren nach Anspruch 2, wobei die Codeüberprüfungshistorie Metadateninformation enthält, die überprüfte Auswahlcodebereiche, eine Menge an überprüften Quellcodes und Feedback- und Verbesserungsrunden enthält.
Verfahren nach Anspruch 1, wobei die Codebereichsdarstellungen ein Erzeugen eines globalen Codezeilenvorlagenwörterbuchs enthalten.
Verfahren nach Anspruch 4, wobei jede Codezeile eines Codebereichs zu dem globalen Codezeilenvorlagenwörterbuch abgebildet wird.
Verfahren nach Anspruch 5, wobei ein Vorkommenshäufigkeit - inverse Dokumenthäufigkeit - (TFIDF(= Term-Frequency Inverse Document Frequency)-) Vektor für jeden Codebereich berechnet wird.
Verfahren nach Anspruch 6, wobei zwei Sätze bzw. Gruppen von Ähnlichkeitsmaßen erzeugt werden, wobei das erste Ähnlichkeitsmaß verwendet wird, um einen Kosinusabstand zwischen zwei beliebigen TFIDF-Vektoren zu berechnen, und ein zweites Ähnlichkeitsmaß verwendet wird, um eine Inhaltsähnlichkeit basierend auf Codezeilenvorlagen zu berechnen.
Verfahren nach Anspruch 7, wobei der Kosinusabstand gegeben ist als: $cos (θ) = \frac{A \cdot B}{‖ A ‖ ‖ B ‖} = \frac{\sum_{i = 1}^{n} A_{i} B_{i}}{\sqrt{\sum_{i = 1}^{n} A_{i}^{2}} \sqrt{\sum_{i = 1}^{n} B_{i}^{2}}}$
wobei A_i und B_i jeweils TFIDF-Werte innerhalb eines bestimmten Codebereichs sind.
Verfahren nach Anspruch 8, wobei ein Organisationsplan in der Lernphase verwendet wird, wobei der Organisationsplan als Baumdiagramm dargestellt wird.
Verfahren nach Anspruch 9, wobei ein Abstand zwischen einem Prüfer, der die Codeüberprüfungsanforderung vorlegt, und irgendeinem Prüferkandidaten auf einer Baumpfadmetrik basiert, die gegeben ist als: $s_{l} (v_{i}, v_{j}) = \frac{1}{1 + l (v_{i}, v_{j})} = \frac{1}{1 + l (v_{i}, l c a_{i j}) + l (v_{j}, l c a_{i j})}$
wobei v_i und v_j zwei Entwickler darstellen, l(vi, v_j) ein kürzester Pfad bzw. Weg zwischen zwei Entwicklern im Organisationsplan ist und I_caij ein niedrigster gemeinsamer Vorfahre zwischen v_i und v_j ist.
Nicht transitorisches bzw. nichtflüchtiges computerlesbares Speichermedium, das ein computerlesbares Programm umfasst, zum automatischen Empfehlen eines Prüfers für vorgelegte Codes, wobei das computerlesbare Programm dann, wenn es auf einem Computer ausgeführt wird, veranlasst, dass der Computer die folgenden Schritte durchführt: Verwenden (801), in einer Lernphase, eines Agenten künstlicher Intelligenz zum Lernen einer zugrundeliegenden und kontextuellen Struktur von Codebereichen; Abbilden (803) der Codebereiche in eine verteilte Darstellung, um Codebereichsdarstellungen zu definieren; Verwenden (805), in einer Empfehlungsphase, des Agenten künstlicher Intelligenz, um eine Rangliste von empfohlenen Prüfern für eine gegebene vorgelegte Codeüberprüfungsanforderung zu erstellen; und Ausgeben (807) der Rangliste von empfohlenen Prüfern zu einer Visualisierungsvorrichtung.
Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 11, wobei die Rangliste von empfohlenen Prüfern auf einer Codeüberprüfungshistorie, einem Codierungsstil, einer Verpflichtungs-Historie und einer Beschäftigungsposition jedes Kandidatenprüfers basiert.
Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 12, wobei die Codeüberprüfungshistorie Metadateninformation enthält, die überprüfte Auswahlcodebereiche, eine Menge an überprüften Quellcodes und Feedback- und Verbesserungsrunden enthält.
Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 11, wobei die Codebereichsdarstellungen ein Erzeugen eines globalen Codezeilenvorlagenwörterbuchs enthalten.
Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 14, wobei jede Codezeile eines Codebereichs zu dem globalen Codezeilenvorlagenwörterbuch abgebildet wird.
Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 15, wobei ein Vorkommenshäufigkeit - inverse Dokumenthäufigkeit - (TFIDF(= Term-Frequency Inverse Document Frequency)-) Vektor für jeden Codebereich berechnet wird.
Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 16, wobei zwei Sätze bzw. Gruppen von Ähnlichkeitsmaßen erzeugt werden, wobei das erste Ähnlichkeitsmaß verwendet wird, um einen Kosinusabstand zwischen zwei beliebigen TFIDF-Vektoren zu berechnen, und ein zweites Ähnlichkeitsmaß verwendet wird, um eine Inhaltsähnlichkeit basierend auf Codezeilenvorlagen zu berechnen.
Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 17, wobei der Kosinusabstand gegeben ist als: $cos (θ) = \frac{A \cdot B}{‖ A ‖ ‖ B ‖} = \frac{\sum_{i = 1}^{n} A_{i} B_{i}}{\sqrt{\sum_{i = 1}^{n} A_{i}^{2}} \sqrt{\sum_{i = 1}^{n} B_{i}^{2}}}$
wobei A_i und B_i jeweils TFIDF-Werte innerhalb eines bestimmten Codebereichs sind.
Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 18, wobei in der Lernphase ein Organisationsplan verwendet wird, wobei der Organisationsplan als Baumdiagramm dargestellt wird; und wobei ein Abstand zwischen einem Prüfer, der die Codeüberprüfungsanforderung vorlegt, und irgendeinem Prüferkandidaten auf einer Baumpfadmetrik basiert, die gegeben ist als: $s_{l} (v_{i}, v_{j}) = \frac{1}{1 + l (v_{i}, v_{j})} = \frac{1}{1 + l (v_{i}, l c a_{i j}) + l (v_{j}, l c a_{i j})}$
wobei v_i und v_j zwei Entwickler darstellen, l(vi, v_j) ein kürzester Pfad bzw. Weg zwischen zwei Entwicklern im Organisationsplan ist und I_caij ein niedrigster gemeinsamer Vorfahre zwischen v_i und v_j ist.
System zum automatischen Empfehlen eines Prüfers für vorgelegte Codes, wobei das System folgendes umfasst: einen Speicher; und einen oder mehrere Prozessoren in Kommunikation mit dem Speicher, konfiguriert, um: in einer Lernphase einen Agenten künstlicher Intelligenz zum Lernen einer zugrundeliegenden und kontextuellen Struktur von Codebereichen zu verwenden (801); die Codebereiche in eine verteilten Darstellung abzubilden (803), um Codebereichsdarstellungen zu definieren; in einer Empfehlungsphase, den Agenten künstlicher Intelligenz zu verwenden (805), um eine Rangliste von empfohlenen Prüfern für eine gegebene vorgelegte Codeüberprüfungsanforderung zu erstellen; und die Rangliste von empfohlenen Prüfern zu einer Visualisierungsvorrichtung auszugeben (807).