Szablon danych cyklu życia oprogramowania

Ten atrybut zawiera datę i godzinę zarejestrowania każdego działania w cyklu wytwarzania oprogramowania. Jest niezbędny do uporządkowania zdarzeń chronologicznie i przeprowadzenia analiz opartych na czasie.

W process mining czas rozpoczęcia służy do obliczania odstępów między działaniami, wykrywania czasu oczekiwania i mierzenia całkowitego czasu realizacji procesu. Jest ważnym elementem dashboardów analizujących wyniki, takich jak analiza całkowitego czasu realizacji SDLC, oraz obliczania KPI, na przykład czasu realizacji przeglądu kodu.

Ten znacznik czasu jest niezbędny do prawidłowego uporządkowania zdarzeń i obliczania wszystkich miar wydajności, w tym czasu realizacji, czasu trwania i czasu oczekiwania.

Zwykle znajduje się w generowanych przez system polach znaczników czasu, takich jak „sys_updated_on” lub „sys_created_on”, w ścieżce audytu albo tabelach zadań.

Element prac rozwojowych pełni funkcję głównego identyfikatora case i reprezentuje odrębną jednostkę pracy podlegającą śledzeniu. Łączy wszystkie działania dotyczące danego elementu, od wstępnego pomysłu i planowania po programowanie, testy i wdrożenie.

W analizie process mining ten atrybut jest podstawą do odtworzenia pełnego przebiegu każdego elementu pracy. Umożliwia wizualizację przepływów procesu, obliczanie całkowitego czasu realizacji i wykrywanie wariantów procesu dla poszczególnych funkcji lub poprawek błędów. Każde zdarzenie w dzienniku musi być powiązane z elementem prac rozwojowych, aby można było utworzyć spójną mapę procesu.

To podstawowy identyfikator, który łączy wszystkie powiązane działania programistyczne w jedną instancję procesu. Dzięki temu można analizować pełny cykl życia każdego elementu pracy.

Zwykle jest to klucz główny z tabel zarządzających historyjkami, błędami lub zadaniami, takich jak tabele „rm_story”, „rm_bug” lub „task” w ServiceNow.

Ten atrybut zapisuje nazwę każdego etapu lub zadania wykonanego w cyklu wytwarzania oprogramowania. Działania te tworzą kolejne kroki procesu, od utworzenia elementu po wdrożenie.

Analiza kolejności i częstotliwości działań to główne zastosowanie process mining. Umożliwia utworzenie mapy procesu, pomaga wykrywać wąskie gardła między etapami i wskazuje odstępstwa od procedur lub nieefektywne warianty procesu. Zdefiniowany zestaw działań obejmuje między innymi projektowanie, programowanie, testowanie i wdrażanie.

Określa kroki na mapie procesu, umożliwiając analizę jego przebiegu, wykrywanie wąskich gardeł i identyfikowanie odstępstw od standardowego SDLC.

Zwykle ustala się ją przez przypisanie zmian statusu, rekordów zdarzeń lub wpisów w ścieżce audytu do standardowej listy nazw działań. Na przykład zmianę pola „state” na „In Progress” można przypisać do działania „Rozpoczęcie programowania”.

Ten atrybut zapisuje datę ostatniego pobrania lub aktualizacji zbioru danych z ServiceNow DevOps. Dotyczy całego zbioru, a nie pojedynczych zdarzeń.

Znacznik czasu pozwala ocenić aktualność analizy. Informuje użytkowników, jak aktualne są wnioski dotyczące procesu, i pomaga zaplanować odświeżanie danych. Wyświetlenie tej informacji na dashboardach zapewnia kontekst dla wszystkich miar i wizualizacji, dzięki czemu decyzje można podejmować na podstawie aktualnych danych.

Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak aktualna jest analiza procesu.

Ten znacznik czasu jest generowany i dodawany podczas pobierania danych. Zapisuje moment wykonania tej operacji.

Ten atrybut wskazuje system źródłowy danych o zdarzeniach. W tym procesie jego wartością będzie zawsze „ServiceNow DevOps”.

Choć może się wydawać, że jest to stała wartość, jawne wskazanie systemu źródłowego ma znaczenie dla nadzoru nad danymi i środowisk, w których łączy się dane z wielu systemów, takich jak Jira lub Azure DevOps. Pozwala ustalić pochodzenie danych i ułatwia diagnozowanie problemów z ich jakością lub pobieraniem.

Zapewnia możliwość śledzenia pochodzenia danych i pomaga zachować ich integralność, zwłaszcza podczas łączenia danych z wielu narzędzi programistycznych.

To stała wartość, którą należy dodać podczas pobierania i przekształcania danych.

To obliczana miara całkowitego czasu realizacji pojedynczego elementu rozwojowego. Wyznacza się ją, obliczając różnicę między znacznikiem czasu pierwszego i ostatniego działania dla każdego case.

Jest to podstawowy KPI dla całego procesu SDLC i bezpośrednio wspiera KPI „Średni czas cyklu SDLC”. Pokazuje ogólne tempo i sprawność procesu. Analiza tej miary w czasie i według różnych wymiarów, takich jak priorytet lub zespół, pozwala śledzić wpływ działań usprawniających proces.

Pokazuje całkowity czas realizacji elementu pracy. To ważna miara ogólnej sprawności i tempa procesu.

To nie jest pole w systemie źródłowym. W narzędziu process mining oblicza się tę wartość dla każdego CaseId, odejmując minimalną wartość StartTime od maksymalnej wartości StartTime.

To atrybut pochodny, który wskazuje działania wykonane po powrocie procesu do wcześniejszego etapu. Na przykład działanie „Rozpoczęcie prac rozwojowych” zostanie oznaczone jako poprawka, jeśli dla tego samego elementu nastąpiło po działaniu „Zakończenie testów QA”.

Ta flaga ułatwia mierzenie i wizualizację poprawek. Bezpośrednio wspiera dashboard „Analiza przepływu poprawek i odrzuceń” i służy do obliczania KPI „Odsetek poprawek po testach”. Analitycy mogą filtrować oznaczone zdarzenia i sprawdzać częstotliwość, przyczyny oraz wpływ poprawek na całkowity czas cyklu.

Flaga ułatwia mierzenie i analizę poprawek, ocenę jakości procesu oraz wykrywanie przyczyn powtarzania pracy.

Atrybut jest obliczany w narzędziu process mining na podstawie sekwencji działań dla każdego case. Pozwala wykryć cofnięcia do wcześniejszych etapów przepływu procesu.

Ten atrybut przypisuje prace rozwojowe do części systemu, której dotyczą. Może to być konkretna mikrousługa, komponent interfejsu użytkownika lub aplikacja backendowa.

Podział procesu według modułu lub komponentu pomaga wykrywać lokalne wąskie gardła. Dashboard „Analiza wąskich gardeł według komponentu” i KPI „Średni czas trwania etapu według komponentu” korzystają z tego atrybutu, aby wskazać, czy określone części bazy kodu regularnie wiążą się z dłuższymi cyklami rozwoju, większą liczbą poprawek lub częstszymi niepowodzeniami wdrożeń. Dzięki temu można skupić działania usprawniające tam, gdzie są najbardziej potrzebne.

Pozwala podzielić analizę według aplikacji lub komponentu, co ułatwia wykrywanie wąskich gardeł i problemów z jakością dotyczących konkretnych części systemu.

Często jest to pole niestandardowe lub odwołanie do Configuration Management Database (CMDB), które łączy element pracy z rekordem „cmdb_ci”. Więcej informacji można znaleźć w dokumentacji ServiceNow DevOps.

Ten atrybut wskazuje zespół, któremu przypisano element pracy, na przykład „Programiści frontend”, „Usługi backendowe” lub „Zespół QA”. W miarę postępu prac element często przechodzi między różnymi grupami przypisania.

Śledzenie grup przypisania pomaga zrozumieć współpracę między zespołami i przekazywanie pracy. Ułatwia wykrywanie opóźnień systemowych pojawiających się przy przekazywaniu zadań z jednego zespołu do drugiego. Atrybut ten pozwala analizować wyniki i obciążenie zespołów oraz wskazywać te, które tworzą wąskie gardła w całym przepływie pracy.

Wskazuje zespół odpowiedzialny za pracę, co pozwala analizować wyniki i obciążenie zespołów, równoważyć pracę oraz oceniać sprawność przekazywania zadań między zespołami.

Informacja jest zapisana w polu „assignment_group”, które standardowo występuje w tabelach związanych z zadaniami w ServiceNow.

Ten atrybut klasyfikuje elementy prac rozwojowych według pilności biznesowej. Poziomy priorytetu pomagają zespołom skupić się na najważniejszych zadaniach i często służą do zarządzania SLA oraz oczekiwaniami interesariuszy.

W process mining priorytet jest ważnym wymiarem analizy porównawczej. Pozwala filtrować mapę procesu i sprawdzać, czy elementy o wysokim priorytecie przebiegają szybciej lub inną ścieżką. Jest niezbędny dla dashboardu i KPI „Czas dostarczenia funkcji o wysokim priorytecie”, które pomagają sprawdzić, czy najważniejsze elementy rzeczywiście są realizowane szybciej.

Umożliwia filtrowanie i porównywanie procesów według poziomu priorytetu, co pomaga sprawdzić, czy elementy o wysokim priorytecie są realizowane szybciej i sprawniej.

To standardowe pole w tabelach zadań w ServiceNow, często nazywane „priority”.

Ten atrybut wskazuje osobę odpowiedzialną za wykonanie konkretnego zadania lub działania. Jego wartość może się zmieniać, gdy element prac rozwojowych przechodzi między etapami i zespołami.

Atrybut ten ma znaczenie przy analizie przydziału zasobów, obciążenia pracą i przekazywania zadań. Zasila dashboard „Obciążenie programistów i przekazywanie zadań” oraz KPI „Liczba działań na programistę”. Śledzenie zmian tego pola pozwala mierzyć czas przekazywania zadań i wykrywać problemy we współpracy między programistami oraz między zespołami programistycznymi i QA.

Jest niezbędny do analiz dotyczących zasobów, w tym rozkładu obciążenia pracą, sprawności przekazywania zadań i wykrywania wzorców wyników charakterystycznych dla poszczególnych zespołów.

Informacja ta jest zwykle przechowywana w polu „assigned_to” w tabelach zadań w ServiceNow.

Ten atrybut określa oficjalny status elementu rozwojowego w ServiceNow. Działania są wyznaczanymi krokami procesu, natomiast stan wskazuje formalny etap zapisany w workflow systemu.

Stan często służy do wyznaczania działań. Można go wykorzystać do walidacji danych i tworzenia prostszych, ogólnych widoków procesu. Analiza czasu spędzonego w poszczególnych stanach pozwala spojrzeć na wąskie gardła z innej perspektywy niż analiza czasu między działaniami. Ułatwia też wykrywanie elementów, które utknęły w procesie lub zostały rozwiązane.

Podaje oficjalny status elementu pracy w systemie. Często na jego podstawie wyznacza się działania, a także weryfikuje dane i analizuje status na wysokim poziomie.

To standardowe pole w tabelach związanych z zadaniami w ServiceNow, zwykle o nazwie „state” lub „stage”.

Ten atrybut rozróżnia rodzaje pracy realizowanej w procesie SDLC. Na przykład naprawa krytycznego błędu może przebiegać inaczej i szybciej niż opracowanie nowej funkcji.

Analiza procesu według typu elementu pracy pozwala lepiej zrozumieć jego wyniki. Ułatwia odpowiedź na pytania takie jak: „Czy błędy częściej wymagają poprawek niż nowe funkcje?” albo „Czy czas redukcji długu technicznego jest akceptowalny?”. Taki podział daje dokładniejszy obraz niż analiza procesu traktująca wszystkie prace jednakowo.

Rozróżnia rodzaje pracy, takie jak funkcje i błędy, które mogą przebiegać różnymi ścieżkami procesu, mieć inne priorytety i przewidywany czas realizacji.

Typ można ustalić na podstawie tabeli źródłowej rekordu (np. „rm_story” lub „rm_bug”) albo pola „type” w ogólnej tabeli zadań.

Ten atrybut zawiera datę i godzinę zakończenia każdego działania w cyklu wytwarzania oprogramowania. Jest szczególnie przydatny w przypadku działań o mierzalnym czasie trwania, takich jak „Przegląd kodu” lub „Testy QA”.

W process mining dostępność czasu rozpoczęcia i zakończenia pozwala dokładnie obliczyć czas realizacji działania i odróżnić go od czasu oczekiwania między działaniami. Dzięki temu można ustalić, czy opóźnienia wynikają z długotrwałych zadań, czy z oczekiwania na zasoby. W przypadku zdarzeń chwilowych, takich jak „Uruchomienie kompilacji”, czas zakończenia może być taki sam jak czas rozpoczęcia.

Umożliwia dokładne obliczenie czasu realizacji działania i odróżnienie czasu pracy od czasu oczekiwania.

Może być konieczne wyliczenie tej wartości. Można ją ustalić na podstawie czasu rozpoczęcia kolejnego działania albo pobrać z osobnego pola „end date”, jeśli jest dostępne w systemie źródłowym.

Ten atrybut bezpośrednio łączy element rozwojowy z konkretną zmianą kodu w repozytorium, na przykład Git. Jest zapisywany przy działaniu „Zatwierdzenie kodu”.

W process mining identyfikator commita wzbogaca analizę, łącząc dane o procesie z danymi inżynieryjnymi. Analitycy mogą prześledzić problematyczne wdrożenie do konkretnej zmiany kodu albo zestawić miary złożoności kodu z czasem cyklu rozwoju. Pozwala to przeprowadzić dokładniejszą analizę przyczyn źródłowych na poziomie technicznym.

Łączy zdarzenie procesu z konkretną zmianą kodu, umożliwiając dokładniejszą analizę przyczyn źródłowych przez zestawienie miar procesu ze szczegółami kodu.

Dane są pobierane przez integracje ServiceNow DevOps z systemami zarządzania kodem źródłowym, takimi jak Git lub SVN. Znajdują się w powiązanych tabelach połączonych z elementem rozwojowym.

Ten atrybut łączy element rozwojowy z konkretnym planowanym wydaniem, na przykład „Wersja 2.3” lub „Wydanie z IV kwartału 2023 r.”. Jest wykorzystywany w zarządzaniu projektami i planowaniu wydań.

W process mining atrybut ten jest niezbędny do działania dashboardu „Monitorowanie realizacji planu wydań”. Porównując rzeczywiste daty zakończenia z planowanymi datami wydań, zespoły mogą mierzyć zgodność z harmonogramem, wykrywać elementy zagrożone opóźnieniem i analizować przyczyny opóźnień wydań. Atrybut łączy szczegółowe dane o procesie rozwoju z celami biznesowymi.

Łączy prace rozwojowe z konkretnymi wydaniami, umożliwiając analizę zgodności z harmonogramem i wpływu opóźnień procesu na terminy wydań.

Informacja jest zwykle zapisana w polu „release” lub „planned_release”, które często odwołuje się do tabeli zarządzania wydaniami w ServiceNow. Więcej informacji można znaleźć w dokumentacji ServiceNow DevOps.

Gdy element nie przejdzie QA lub UAT, ten atrybut zapisuje przyczynę niepowodzenia. Może nią być określona kategoria błędu, błędna interpretacja wymagań lub problem ze środowiskiem.

Informacja ta dostarcza kontekstu potrzebnego do analizy w dashboardzie „Analiza przepływu poprawek i odrzuceń”. Zamiast ograniczać się do stwierdzenia, że wykonano poprawki, analitycy mogą ustalić, dlaczego były potrzebne. Ułatwia to wdrażanie ukierunkowanych usprawnień, takich jak dokładniejsze definiowanie wymagań, lepsze testy jednostkowe lub stabilniejsze środowiska testowe, aby ograniczyć liczbę poprawek.

Wyjaśnia, dlaczego potrzebne są poprawki, co pozwala ukierunkować usprawnienia procesu, podnieść jakość i ograniczyć powtarzanie pracy.

Informacja może być zapisana w polu „close_notes” po nieudanym teście lub w dedykowanym polu niestandardowym „rework_reason”. Więcej informacji można znaleźć w dokumentacji ServiceNow DevOps.

Ten atrybut zapisuje wynik wdrożenia w konkretnym środowisku. Pomaga ocenić niezawodność i stabilność procesu wydawania oprogramowania.

Atrybut ten jest niezbędny do działania dashboardu „Trendy powodzeń i niepowodzeń wdrożeń” oraz KPI „Odsetek nieudanych wdrożeń”. Analiza częstotliwości i trendów nieudanych wdrożeń pozwala organizacjom wykrywać problemy związane z testowaniem, infrastrukturą lub koordynacją wydań. Dzięki temu można skupić działania na poprawie jakości i niezawodności dostarczania oprogramowania.

Bezpośrednio mierzy powodzenie działań wdrożeniowych. Jest niezbędny do obliczenia odsetka nieudanych wdrożeń i analizy stabilności wydań.

Status jest zwykle zapisywany w zadaniach śledzących wdrożenia lub w rekordach wykonań potoków CI/CD zintegrowanych z ServiceNow DevOps.