Architektura aplikacji do śledzenia defektów

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.