Freigeben über


Fehlerdashboard (CMMI)

Sie können die Fehleraktivität für ein Teamprojekt mithilfe der folgenden Diagramme im Fehlerdashboard überwachen:

  • Fehlerburndown

  • Die Rate, mit der das Team Fehler über einen bestimmten Zeitraum findet, behebt und schließt

  • Die Anzahl von Fehlern mit Priorität im Zeitverlauf

  • Die aktuelle Anzahl von aktiven Fehlern, die jedem Teammitglied zugewiesen wurden

    Tipp

    Sie greifen über das Teamprojektportal auf Dashboards zu. Sie können auf das Fehlerdashboard nur zugreifen, wenn dieses Portal aktiviert wurde und die Verwendung von Microsoft Office SharePoint Server 2007 für das Teamprojektportal zulässig ist. Weitere Informationen finden Sie unter Dashboards (CMMI) oder Zugreifen auf Teamprojektportale und Prozessleitfäden.

In diesem Thema

  • Im Dashboard angezeigte Daten

  • Erforderliche Aktivitäten zum Nachverfolgen von Fehlern

  • Überwachen von aktiven Fehlern und Fehlertrends

Sie können mit diesem Dashboard die folgenden Fragen beantworten:

  • Wie schnell werden Fehler vom Team behoben und geschlossen?

  • Werden Fehler vom Team ausreichend schnell behoben, um das Projekt termingerecht abzuschließen?

  • Wie viele Fehler werden vom Team pro Tag gemeldet, behoben und geschlossen?

  • Behebt das Team Fehler mit Priorität 1 vor Fehlern mit Priorität 2 und 3?

  • Liegt für ein Teammitglied ein Rückstand an Fehlern mit der Priorität 1 vor, die eine Neuverteilung erforderlich macht?

  • Wie lautet der Status des Builds von letzter Nacht?

  • Was wurde zuletzt eingecheckt?

Erforderliche Berechtigungen

Zum Anzeigen des Dashboards müssen Sie einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der in SharePoint-Produkte die Berechtigung Lesen für das Teamprojekt zugewiesen wurde. Zum Ändern, Kopieren oder Anpassen des Dashboards müssen Sie einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der in SharePoint-Produkte die Berechtigung Mitglieder für das Teamprojekt zugewiesen wurde. Weitere Informationen finden Sie unter Hinzufügen von Benutzern zu Teamprojekten.

Zum Ändern eines Berichts in Office Excel müssen Sie Mitglied der Sicherheitsrolle TfsWarehouseDataReaders in SQL Server Analysis Services sein. Sie müssen außerdem einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der in SharePoint-Produkte die Berechtigung Mitglieder für das Teamprojekt zugewiesen wurde. Weitere Informationen finden Sie unter Gewähren von Zugriff auf die Datenbanken des Data Warehouse für Visual Studio ALM.

Zum Anzeigen eines Fehlers oder anderen Arbeitsaufgabentyps müssen Sie Mitglied der Gruppe Leser sein, oder die Berechtigung Arbeitsaufgaben in diesem Knoten anzeigen muss auf Zulassen festgelegt sein. Zum Erstellen oder Ändern eines Fehlers oder anderen Arbeitsaufgabentyps müssen Sie Mitglied der Gruppe Contributors sein, oder die Berechtigung Arbeitsaufgaben in diesem Knoten bearbeiten muss auf Zulassen festgelegt sein. Weitere Informationen finden Sie unter Verwalten von Berechtigungen.

Im Dashboard angezeigte Daten

Das Team kann mithilfe des Fehlerdashboards ermitteln, wie erfolgreich es Fehler findet, behebt und schließt. Insbesondere werden im Dashboard die Webparts angezeigt, die in der folgenden Abbildung dargestellt und in der folgenden Tabelle beschrieben werden:

Fehlerdashboard

Tipp

Status-, Trend- und Balkendiagramme und die Berichte Schritt 1 bis Schritt 4 werden nicht angezeigt, wenn der Server, auf dem Analysis Services gehostet werden, nicht verfügbar ist.

Weitere Informationen zum Interpretieren, Aktualisieren oder Anpassen der Diagramme, die im Fehlerdashboard angezeigt werden, finden Sie in den in der folgenden Tabelle aufgeführten Themen.

Webpart

Angezeigte Daten

Verwandtes Thema

Schritt 1

Eine visuelle Darstellung der kumulierten Anzahl aller Fehler, nach Zustand gruppiert, für die letzten vier Wochen.

Excel-Bericht "Fehlerstatus"

Excel-Bericht Fehlerstatus

Schritt 2

Ein Liniendiagramm, das den gleitenden Durchschnitt der Anzahl von Fehlern darstellt, die während der letzten vier Wochen vom Team geöffnet, behoben und geschlossen wurden. Der gleitende Durchschnitt basiert auf den sieben Tagen vor dem Datum der Berechnung.

Bericht über Fehlertrends

Excel-Bericht Fehlertrends

Schritt 3

Eine visuelle Darstellung der kumulierten Anzahl aller Fehler, nach Priorität gruppiert, für die letzten vier Wochen.

Fehler von Prioritätsdiagramm

Excel-Bericht Fehler nach Priorität

Schritt 4

Ein horizontales Balkendiagramm, das die Gesamtanzahl von aktiven Fehlern, die jedem Teammitglied zurzeit zugewiesen sind, nach Priorität gruppiert darstellt.

Fehler von Zuweisungsdiagramm

Excel-Bericht Fehler nach Zuweisung

Schritt 5

Liste der aktiven Fehler. Die Liste wird von einem Team Web Access-Webpart abgeleitet.

Bericht über Fehlertrends

Nicht zutreffend

Schritt 6

Liste bevorstehender Ereignisse. Die Liste wird von einem SharePoint-Webpart abgeleitet.

Ereignisse-Webpart importieren

Nicht zutreffend

Schritt 7

Anzahl der aktiven, gelösten und geschlossenen Arbeitsaufgaben. Sie können die Liste der Arbeitsaufgaben öffnen, indem Sie auf die einzelnen Zahlen klicken. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.

Projektarbeitsaufgaben

Arbeitsaufgaben und Workflow (CMMI)

Schritt 8

Liste der letzten Builds und ihrer Status. Sie können weitere Informationen zu einem Build anzeigen, indem Sie darauf klicken. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.

Letzte Builds-Webpart

Legende:

Buildvorgang wird ausgeführt: Der Buildvorgang wird ausgeführt.

Buildvorgang nicht gestartet: Der Buildvorgang wurde nicht gestartet.

Der Buildvorgang war erfolgreich: Der Buildvorgang war erfolgreich.

Fehler beim Buildvorgang: Der Buildvorgang ist fehlgeschlagen.

Der Buildvorgang wurde beendet: Der Buildvorgang wurde beendet.

Buildvorgang teilweise erfolgreich: Der Buildvorgang war teilweise erfolgreich.

Verwalten und Anzeigen von abgeschlossenen Builds

9

Liste der letzten Eincheckvorgänge. Sie können weitere Informationen zu einem bestimmten Eincheckvorgang anzeigen, indem Sie darauf klicken. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.

Letzte Eincheckvorgänge-Webpart

Verwenden der Fenster Einchecken und Ausstehende Änderungen

Erforderliche Aktivitäten zum Nachverfolgen von Fehlern

Damit die im Fehlerdashboard angezeigten Berichte aussagekräftig und genau sind, muss das Team die folgenden Aktivitäten ausführen:

  • Definieren Sie Fehler, und geben Sie die zugehörigen Pfade Iteration und Bereich an.

  • Weisen Sie jeden Fehler dem Teammitglied zu, das den Fehler auflösen oder schließen kann.

  • Geben Sie die Priorität jedes Fehlers an.

  • Aktualisieren Sie den Zustand jedes Fehlers, wenn er vom Team behoben, überprüft oder geschlossen wird.

Überwachen von aktiven Fehlern und Fehlertrends

Teammitglieder können mithilfe des Fehlerdashboards feststellen, ob die Liste der aktiven Fehler entsprechend den festgelegten Teamzielen und agilen Verfahren verwaltet wird. Wenn für jedes Inkrement des Codes vor dem Einchecken Komponententests ausgeführt werden, kann das Team die Gesamtanzahl zu suchender Fehler reduzieren. Ein Team, das sich darauf konzentriert, jedes Codeinkrement liefern zu können, entfernt Fehler inkrementell und minimiert so laufende Fehler.

Mit dem Fehlerdashboard kann das Team die folgenden Fragen beantworten:

  • Ist die Anzahl der aktiven Fehler im Hinblick auf die Teamziele akzeptabel? Stellt das Team zu viele Fehler zurück?

  • Sucht, behebt und schließt das Team Fehler schnell genug, um die Erwartungen zu erfüllen, und mit einer Rate, die der von vorherigen Entwicklungszyklen entspricht?

  • Behandelt das Team Fehler mit hoher Priorität vor Fehlern mit niedrigerer Priorität?

  • Benötigt ein Teammitglied Hilfe beim Beheben von Fehlern?

Weitere Fragen, die auf Grundlage der in diesem Dashboard angezeigten Indikatoren gestellt werden können, finden Sie in den folgenden Abschnitten:

  • Fehlerstatusindikatoren

  • Trendindikatoren

  • Priorität und Verteilung von Fehlern

Fehlerstatusindikatoren

Indikator

Wichtige Fragen

Das Band für aktive Fehler wird breiter. Wenn die Breite des Bands für aktive Fehler zunimmt, wächst der Fehlerrückstand. Das Team findet mehr Fehler als es beheben oder schließen kann.

Ein zunehmend breites Band aktiver Fehler kann darauf hinweisen, dass das Team aufgrund eines Engpasses keine Fehler beheben und schließen kann.

  • Werden Teammitglieder anderen Aufgaben ohne Priorität zugewiesen?

  • Blockieren andere Probleme die Fähigkeit des Teams, Fehler zu beheben und zu korrigieren?

Die Anzahl aktiver Fehler ändert sich nicht. Ein flacher Trend in der Anzahl aktiver Fehler weist darauf hin, dass das Team keine Fehler findet.

  • Ist die Testabdeckung ausreichend?

  • Blockieren andere Probleme die Fähigkeit des Teams, Fehler zu finden?

Die Anzahl behobener oder geschlossener Fehler ändert sich nicht. Wenn die Anzahl der vom Team behobenen oder geschlossenen Fehler über lange Zeiträume unverändert ist, sind die Teammitglieder möglicherweise nicht in der Lage, Fehler zu beheben oder zu schließen.

  • Sind die Teamprioritäten richtig festgelegt?

  • Wurden anderen Aufgaben zu viele Teammitglieder zugewiesen?

  • Verfolgen die Teammitglieder ihren Fehlerstatus ordnungsgemäß nach?

Fehlertrendindikatoren

Indikator

Wichtige Fragen

Das Team behebt in jedem Zeitraum eine große Anzahl von Fehlern. Eine hohe Behebungsrate zeigt normalerweise einen guten Fortschritt des Teams an.

  • Schließt das Team die behobenen Fehler sofort? Die Rate der Schließungen sollte der Rate der Behebungen entsprechen.

  • Ist die Rate der Fehlerreaktivierungen akzeptabel?

Fehler werden vom Team schnell behoben, jedoch nicht geschlossen. Möglicherweise sind zu wenig Teammitglieder für die Überprüfung von Fehlerkorrekturen zugewiesen, oder diese Teammitglieder werden durch andere Prioritäten vom Schließen behobener Fehler abgehalten.

  • Sind die Testressourcen zu stark ausgelastet?

  • Sollten die Testprioritäten vom Team überarbeitet werden?

    Weitere Informationen zu diesen Metriken finden Sie unter Testdashboard (CMMI).

Das Team findet in jedem Zeitraum eine geringe Anzahl von Fehlern. Möglicherweise hat das Team Probleme, Fehler in qualitativ hochwertigen Lösungen oder mit ineffektiven Tests zu finden.

  • Weisen die Metriken für Codeabdeckung, Codeänderung oder Teststatus auf ein Problem mit dem Code oder mit den Tests hin?

    Weitere Informationen zu diesen Metriken finden Sie unter Qualitätsdashboard (CMMI).

Das Team findet in aufeinander folgenden Zeiträumen etwa dieselbe Anzahl von Fehlern. Wenn das Team Woche für Woche oder Iteration für Iteration stets dieselbe Anzahl von Fehlern findet, empfiehlt es sich, die Ursache für dieses Muster zu untersuchen. In einer frühen Phase des Testzyklus sind die Tests möglicherweise nicht strikt oder ausgereift genug, um viele Fehler zu finden. In frühen Iterationen ist diese Situation zu erwarten. Mit fortschreitender Entwicklung des Produkts sollten die Tests jedoch umfassendere Szenarien und Integrationen abdecken.

  • Sind die Tests ausreichend, um die vom Team entwickelten Anforderungen zu testen?

  • Sind die Tests veraltet, oder werden die falschen Funktionen getestet?

  • Werden strikte Tests für alle Anforderungen ausgeführt?

    Weitere Informationen zu diesen Metriken finden Sie unter Testdashboard (CMMI).

Das Team findet in jedem Zeitraum eine große Anzahl von Fehlern. In qualitativ minderwertigem Code, in neu integriertem Code, durch effektive Tests oder während bestimmter Ereignisse (z. B. bei auftretenden Defekten) kann das Team viele Fehler finden.

  • Weisen die Metriken für Codeabdeckung, Codeänderung oder Teststatus auf ein Problem mit dem Code oder mit den Tests hin?

    Weitere Informationen zu diesen Metriken finden Sie unter Qualitätsdashboard (CMMI).

Fehlerpriorität und Verteilung

Indikator

Wichtige Fragen

Die Anzahl aktiver Fehler mit höherer Priorität ist größer als die Anzahl aktiver Fehler mit niedrigerer Priorität. Wenn die Anzahl der Fehler mit hoher Priorität viel größer ist als die Anzahl der Fehler mit niedrigerer Priorität, konzentriert sich das Team möglicherweise zuerst auf Elemente mit niedrigerer Priorität.

  • Behebt das Team Programmfehler in der vom Team festgelegten Dringlichkeitsfolge?

  • Wird die Fähigkeit des Teams, die Fehler mit höherer Priorität zu beheben, durch Probleme blockiert?

Fehlerzuweisungen sind nicht gleichmäßig verteilt. Wenn einem oder zwei Teammitgliedern deutlich mehr Fehler zugewiesen wurden als anderen Teammitgliedern, sollte das Team eine erneute Zuweisung der Arbeit erwägen.

  • Sollte das Team die Arbeitsauslastung neu verteilen, indem Fehler neu zugewiesen werden?

Siehe auch

Konzepte

Suchen nach Fehlern, Aufgaben und anderen Arbeitsaufgaben

Weitere Ressourcen

Fehler (CMMI)

Excel-Berichte (CMMI)

Dashboards (CMMI)

Artefakte (CMMI)