Architektura aplikacji do śledzenia defektów
  • 04 Nov 2023
  • 2 Minuty do przeczytania
  • Współtwórcy

Architektura aplikacji do śledzenia defektów


Streszczenie artykułu

Struktura aplikacji

Ten Functional Example jest pojedynczą aplikacją w bibliotece Tulip, ale większość wartości pochodzi z aplikacji Tulip, gdy dedykowane aplikacje mogą być budowane w celu wspierania różnych ról i potrzeb użytkowników.

Starsze rozwiązania do śledzenia defektów w najlepszym przypadku są błędnymi, jednorazowymi rozwiązaniami punktowymi, aw najgorszym przypadku obejmują dziesiątki losowych arkuszy Excela, formularzy papierowych i wiele godzin spędzonych na ręcznym wprowadzaniu danych.

Śledzenie defektów jest nieco wyjątkowym problemem, ponieważ najlepsze rozwiązania do śledzenia defektów istnieją w kontekście (w ramach procesu, w którym można znaleźć defekt), więc najlepsze rozwiązania do śledzenia defektów powinny być użyteczne we wszystkich aplikacjach procesowych, w których można znaleźć defekty. Przejścia aplikacji mogą być używane do przenoszenia użytkowników z dowolnej aplikacji procesowej do centralnej aplikacji do śledzenia defektów lub funkcja raportowania defektów może być kopiowana we wszystkich aplikacjach.

Jedna centralna aplikacja do śledzenia defektów

ZALETY:

  • Zmiany w procesie zarządzania defektami są proste, jeden punkt zmian
  • Oddzielny zespół może zarządzać wersjami aplikacji w przeciwieństwie do aplikacji procesowych.

WADY:

  • Bardziej chaotyczne doświadczenie użytkownika, ponieważ defekty są wprowadzane w oddzielnej aplikacji
  • Zarządzanie zmiennymi w wielu aplikacjach może wymagać nieco więcej wyzwalaczy.

Raportowanie usterek w każdej aplikacji

ZALETY:

  • Doświadczenie użytkownika jest bardziej płynne.
  • Procesy z różnymi typami usterek mogą mieć różne interfejsy użytkownika, aby lepiej obsługiwać swoje standardowe usterki.
  • Zarządzanie zmiennymi aplikacji jest prostsze.

WADY:

  • Wiele punktów zmian w przypadku zmian procesu. Zmiany te musiałyby zostać zastosowane do każdej aplikacji jednorazowo.
  • Ten sam zespół, który zarządza aplikacją procesową, byłby właścicielem śledzenia defektów dla każdej z tych aplikacji.

Podział aplikacji

Functional Example dla Defect Tracking służy jako podstawowa funkcjonalność potrzebna do śledzenia defektów:

  • Zgłaszanie defektów
  • Edycja raportów defektów
  • (opcjonalnie) Drukowanie etykiet defektów do kwarantanny
  • Wyświetlanie defektów
  • Aktualizowanie kolejnych kroków i statusu
  • Wyświetlanie historii usterek
  • Uzyskiwanie wglądu w defekty za pomocą funkcji Analytics

Jak pokazuje przykład funkcjonalny, wszystkie funkcje można połączyć w jednej aplikacji lub dowolną z jej podstawowych funkcji można wykorzystać w aplikacjach bardziej segmentowych.

W obu przypadkach (wymienionych powyżej) Tulip zaleca przeniesienie funkcji edycji i usuwania usterek do oddzielnej aplikacji, do której dostęp mają tylko użytkownicy ze specjalnymi uprawnieniami. Umożliwia to większą kontrolę nad tym, którzy użytkownicy mogą edytować dane o krytycznym znaczeniu dla jakości.


Czy ten artykuł był pomocny?