---
title: "Defect Tracking App Architecture"
slug: "defect-tracking-app-architecture"
updated: 2023-11-04T15:33:44Z
published: 2023-11-04T15:33:44Z
canonical: "support.tulip.co/defect-tracking-app-architecture"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.tulip.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Architektur der Defektverfolgungs-App



## App-Struktur

Dieses Functional Example ist eine einzelne Anwendung in der Tulip-Bibliothek, aber ein Großteil des Wertes von Tulip-Apps liegt darin, dass dedizierte Anwendungen zur Unterstützung verschiedener Benutzerrollen und -bedürfnisse erstellt werden können.

Ältere Lösungen zur Fehlerverfolgung sind im besten Fall fehlerbehaftet und punktuell, im schlimmsten Fall bestehen sie aus Dutzenden von Excel-Tabellen, Papierformularen und vielen Stunden manueller Dateneingabe.

Die Fehlerverfolgung ist ein einzigartiges Problem, da die besten Lösungen für die Fehlerverfolgung kontextbezogen sind (innerhalb des Prozesses, in dem der Fehler gefunden werden kann), so dass die besten Lösungen für die Fehlerverfolgung in allen Prozessanwendungen, in denen Fehler gefunden werden können, einsetzbar sein sollten. App Transitions können verwendet werden, um Benutzer von einer beliebigen Prozessanwendung zu einer zentralen Fehlerverfolgungsanwendung zu bewegen, oder die Fehlerberichtsfunktion kann in alle Ihre Anwendungen kopiert werden.

### Eine zentrale App zur Fehlerverfolgung

**PROS**:

- Änderungen am Fehlerverwaltungsprozess sind einfach, eine Stelle für Änderungen
- Ein separates Team kann die App-Versionen im Gegensatz zu den Prozess-Apps verwalten

**CONS**:

- Uneinheitlichere Benutzererfahrung, da Fehler in einer separaten App eingegeben werden
- Die Verwaltung von Variablen über mehrere Apps hinweg kann etwas triggerintensiver sein.

### Fehlerberichterstattung in jeder App

**PROS**:

- Die Benutzererfahrung ist nahtloser.
- Prozesse mit unterschiedlichen Fehlertypen können unterschiedliche Benutzeroberflächen haben, um ihre Standardfehler besser zu unterstützen.
- Die Verwaltung von App-Variablen ist einfacher.

**CONS**:

- Viele Änderungspunkte, wenn Prozessänderungen vorgenommen werden. Diese Änderungen müssten einmalig auf jede App angewendet werden.
- Dasselbe Team, das die Prozess-App verwaltet, würde auch die Fehlerverfolgung für jede dieser Apps übernehmen.

## App-Aufgliederung

Das Functional Example für Defect Tracking dient als Kernfunktionalität für die Fehlerverfolgung:

- Defekte melden
- Bearbeiten von Fehlerberichten
- (optional) Drucken von Fehleretiketten für die Quarantäne
- Defekte ansehen
- Nächste Schritte und Status aktualisieren
- Fehlerhistorie anzeigen
- Erkenntnisse über Defekte mit Analytics gewinnen

Wie das Funktionsbeispiel zeigt, kann die gesamte Funktionalität in einer einzigen Anwendung kombiniert werden, oder jede der Kernfunktionen kann in mehreren Segmentanwendungen genutzt werden.

Bei beiden Ansätzen (siehe oben) empfiehlt Tulip, die Bearbeitungs- und Dispositionsfunktionen von Mängeln in eine separate Anwendung zu verlagern, zu der nur Benutzer mit speziellen Berechtigungen Zugang haben. Dies ermöglicht eine bessere Kontrolle darüber, welche Benutzer qualitätskritische Daten bearbeiten können.

**Functional Example**

**Functional Examples** are intended to explain the right approach to core Tulip use cases. Functional example applications cover the core applications, their underlying data models, and ways those concepts can be extended when combined with others.

*Functional Example apps aren't intended to be run in production, but rather as tools to learn the underlying concepts needed to implement core Tulip use cases.*