Szablon: Specyfikacja konfiguracji i raportu (IDK-12)

Szablon IDK-12, wersja 1.0. Faza: Establish Solution.

Jak korzystać z tego szablonu

Użyj jednej specyfikacji na każdą konfigurację lub raport w rejestrze CRIM (szablon Rejestr CRIM (IDK-10)): pola niestandardowe, Custom Events, konfiguracje stron, lobby, workflow, Quick Reports i raporty operacyjne. Integracje i modyfikacje używają szablonu IDK-11.
Wypełnij sekcje 1-3 dla każdego obiektu. W sekcji 4 zostaw tylko blok pasujący do typu obiektu, usuń pozostałe.
Budowa zaczyna się dopiero po zatwierdzeniu przez kierownika projektu po stronie klienta w sekcji 9. Zmiany po zatwierdzeniu przechodzą przez kontrolę zmian.
Trzymaj to krótko. Dobra specyfikacja konfiguracji mieści się na kilku stronach i może zostać przeczytana przez właściciela procesu.
Zastąp każde pole [...]. Usuń wiersze oznaczone Przykład: przed zatwierdzeniem.

Metadane szablonu
Field	Value
ID szablonu	IDK-12
Faza	Establish Solution
Właściciel	Konsultant aplikacyjny lub analityk techniczny po stronie klienta
Zatwierdzający	Kierownik projektu po stronie klienta
Bramka kwalifikacyjna	Solution Established
Wersja	1.0

Kontrola dokumentu

Pole	Wartość
Projekt	[nazwa projektu]
ID rejestru CRIM	[ID]
Typ obiektu	[Pole niestandardowe / Custom Event / Konfiguracja strony / Lobby / Workflow / Quick Report / Raport operacyjny / Inny]
Obszar rozwiązania i proces	[obszar, proces, link do modelu procesów]
Autor	[imię i nazwisko, rola]
Wykonawca	[imię i nazwisko, rola]
Status	[Szkic / W przeglądzie / Zatwierdzona / Zbudowana / Przetestowana / Zaakceptowana]
Lokalizacja przechowywania	[link]

Wersja	Data	Autor	Zmiana	Zatwierdził
0.1	[YYYY-MM-DD]	[imię i nazwisko]	Pierwszy szkic
[x.y]	[YYYY-MM-DD]	[imię i nazwisko]	[zmiana]	[imię i nazwisko]

1. Potrzeba biznesowa i alternatywa standardowa

Pozycja	Opis
Potrzeba biznesowa	Przykład: Odbiorcy towaru muszą widzieć przy przyjęciu, czy pozycja zamówienia zakupu wymaga certyfikatu dostawcy, żeby towar bez niego trafiał na lokalizację kwarantanny
Zgłosił	[imię i nazwisko, rola biznesowa]
Odniesienie do Księgi reguł	[dokument, ID decyzji]
Rozważona alternatywa standardowa	Przykład: Pokazano pole tekstowe uwag na pozycji zamówienia zakupu. Jest to wolny tekst, nie da się go wyszukać ani zrobić obowiązkowym, i często zostaje puste.
Dlaczego konfiguracja jest uzasadniona	[tekst]
Konsekwencja, jeśli nie dostarczona	[tekst]

2. Obiekt i kontekst

Pozycja	Opis
Nazwa obiektu	[nazwa zgodna z konwencją nazewnictwa projektu]
Odniesienie do konwencji nazewnictwa	[link. Uzgodnij prefiks, żeby obiekty klienta były łatwe do znalezienia przy aktualizacji.]
Strona, encja lub raport, do którego obiekt należy	Przykład: Encja pozycji zamówienia zakupu, pokazana na stronie zamówienia zakupu i na stronie rejestracji przyjęcia
Kontekst konfiguracji (konfiguracje stron)	[globalny albo nazwany kontekst i reguła mapująca użytkowników lub lokalizacje na niego]
Lokalizacje i spółki objęte zakresem	[lista]
Role biznesowe, które go używają	[role]
Powiązane obiekty CRIM	[ID]

3. Logika w prostym języku

Opisz, co robi obiekt, tak żeby właściciel procesu mógł to potwierdzić. Jeden krótki akapit albo lista numerowana.

Przykład:

Kupiec zaznacza „Wymagany certyfikat" na pozycji zamówienia zakupu, gdy indeks należy do regulowanej grupy indeksów.
Odbiorca towaru widzi to pole, tylko do odczytu, przy rejestracji przyjęcia.
Gdy pole jest zaznaczone, a certyfikat nie jest dołączony, powiadomienie trafia do roli jakości.

[Twój tekst]

4. Szczegóły obiektu

Zostaw blok, który pasuje. Usuń resztę.

4.1 Pole niestandardowe

Pozycja	Wartość
Encja	[nazwa encji jak pokazana w konfiguracji encji]
Nazwa pola i etykieta	Przykład: `CERT_REQUIRED`, etykieta „Wymagany certyfikat"
Typ danych i długość	Przykład: Logiczny (Boolean)
Trwałe czy tylko do odczytu (obliczane)	[Trwałe / Tylko do odczytu, z wyrażeniem dla pól obliczanych]
Wartość domyślna	[wartość]
Obowiązkowe	[Tak / Nie, i od jakiego statusu]
Lista wartości lub odniesienie	[wartości enumeracji albo referencjonowana encja]
Strony, na których pole jest umieszczone	[strona, grupa, pozycja]
Potrzebne w raportach, lobby, integracjach lub migracji	[lista, z ID CRIM]
Potrzebne tłumaczenia	[języki]

4.2 Custom Event i akcja zdarzenia

Pozycja	Wartość
Encja i tabela, której słucha zdarzenie	[nazwa]
Wyzwala się przy	[nowy rekord / zmodyfikowany rekord / usunięty rekord, i na jakich atrybutach]
Warunek	Przykład: Wymagany certyfikat jest prawdą, a status pozycji zmienia się na dostarczona
Typ akcji	[E-mail / Komunikat Streams / Wykonanie SQL online / Wywołanie REST / Inny]
Odbiorcy lub cel	[adres oparty na roli lub dystrybucji, nie nazwana osoba]
Treść komunikatu	[temat i treść, z użytymi polami podstawianymi]
Oczekiwana częstotliwość	`[ustalić w projekcie]`
Co się dzieje, gdy akcja zawiedzie	[tekst. Akcja zdarzenia, która zgłasza błąd, może zablokować transakcję użytkownika. Podaj zamierzone zachowanie.]

4.3 Konfiguracja strony

Pozycja	Wartość
Strona	[nazwa strony i pozycja w nawigatorze]
Zmiana	Przykład: Dodanie pola niestandardowego do grupy pozycji, ukrycie dwóch nieużywanych pól, domyślna widoczność kolumny potwierdzonej daty
Kontekst konfiguracji	[kontekst]
Formatowanie warunkowe lub reguły obowiązkowości	[reguła]
Zrzuty ekranu przed i po	[link]
Interakcja z personalizacją użytkownika	[uwaga, czy własne zapisane układy użytkowników są dotknięte]

4.4 Lobby

Pozycja	Wartość
Nazwa strony lobby	Przykład: Strona startowa kupca
Odbiorcy	[role biznesowe]
Parametry strony	[np. lokalizacja, kupiec, zakres dat]

Element	Typ	Źródło danych	Filtr i grupowanie	Cel drążenia	Oczekiwanie odświeżania
Przykład: Niepotwierdzone pozycje	Licznik z listą	Pozycje zamówień zakupu	Zwolnione pozycje bez potwierdzenia, wg kupca, starsze niż `[ustalić w projekcie]` dni	Strona pozycji zamówień zakupu z tym samym filtrem	Przy ładowaniu strony
[element]	[typ]	[źródło danych]	[filtr]	[cel]	[oczekiwanie]

Uwaga o wydajności: [oczekiwana liczba wierszy dla każdego źródła danych i wszelkie źródła danych wymagające indeksu lub węższego filtra].

4.5 Workflow (Business Process Automation)

Pozycja	Wartość
Nazwa workflow	[nazwa]
Cel	[walidacja / wzbogacenie danych / interakcja z użytkownikiem / proces w tle]
Wyzwalacz	[projekcja i akcja albo operacja na encji, która go uruchamia, oraz moment względem standardowej logiki]
Kroki	[lista numerowana albo link do diagramu BPMN]
Odczytywane i zapisywane dane	[projekcje, encje, pola]
Komunikaty pokazywane użytkownikowi	[tekst i język]
Zachowanie przy niepowodzeniu	[czy transakcja użytkownika jest zatrzymywana i jaki komunikat jest pokazywany]
Oczekiwany wolumen	`[ustalić w projekcie]`

4.6 Quick Report

Pozycja	Wartość
Nazwa raportu i kategoria	[nazwa, kategoria]
Typ	[instrukcja SQL / zapytanie zaprojektowane w kliencie]
Parametry	[nazwa, typ, domyślna, obowiązkowa]
Kolumny	[kolumna, źródło, format]
Logika selekcji w prostym języku	Przykład: Wszystkie otwarte pozycje zamówień zakupu, gdzie obiecana data jest wcześniejsza niż dziś, dla lokalizacji, które użytkownik ma prawo widzieć
Źródła danych	[widoki lub projekcje. Podaj, jak respektowany jest dostęp do lokalizacji i spółki.]
Oczekiwana liczba wierszy i czas wykonania	`[ustalić w projekcie]`
Sposób wykorzystania wyniku	[na ekranie / eksport / zaplanowane]

4.7 Raport operacyjny

Pozycja	Wartość
Standardowy raport użyty jako baza	Przykład: Wydruk zamówienia zakupu
Nazwa layoutu	[nazwa]
Zmiany w layoucie	[logo, blok adresowy, dodane lub usunięte kolumny, tekst warunków]
Potrzebne dodatkowe pola	[pole, źródło. Zaznacz, czy dane raportu muszą zostać rozszerzone, co podnosi poziom dostosowania.]
Języki	[lista]
Format papieru i kanał wyjściowy	[format, druk, e-mail, archiwum]
Treść wymagana prawnie lub przez klienta	[tekst i osoba, która go potwierdziła]
Makieta layoutu	[link]

5. Dotknięte permission sety

Permission set	Zmiana	Powód	Poinformowano właściciela bezpieczeństwa
Przykład: [permission set roli kupca]	Przyznanie dostępu do strony lobby i jej źródeł danych	Kupcy otwierają ją jako stronę startową	[imię i nazwisko, data]
Przykład: [permission set odbiorcy towaru]	Dostęp do odczytu pola niestandardowego, bez edycji	Pole jest utrzymywane wyłącznie przez kupców	[imię i nazwisko, data]
[permission set]	[zmiana]	[powód]	[imię i nazwisko, data]

Testuj na koncie użytkownika końcowego posiadającym wyłącznie wymienione permission sety. Obiekt, który działa dla administratora, niczego nie dowodzi.

6. Przypadki testowe

ID testu	Klasa	Rola logowania	Warunki wstępne i dane	Kroki	Oczekiwany wynik	Wynik, tester, data
Przykład: T1	Typowy	Odbiorca towaru	Pozycja zamówienia zakupu z zaznaczonym „Wymagany certyfikat"	Otwarcie rejestracji przyjęcia dla pozycji	Pole jest widoczne i tylko do odczytu	[Zaliczony / Niezaliczony], [imię i nazwisko], [YYYY-MM-DD]
Przykład: T2	Wyjątek normalny	Kupiec w innej lokalizacji	Ta sama pozycja	Otwarcie zamówienia zakupu	Zamówienie niedostępne, zgodnie z dostępem wg lokalizacji
[ID]	[Typowy / Wyjątek normalny / Wyjątek specyficzny]	[rola]	[dane]	[kroki]	[oczekiwane]

Uwzględniony w skrypcie SAT: [ID].

7. Nota o bezpieczeństwie aktualizacji

Pozycja	Opis
Poziom dostosowania	Konfiguracja, chyba że sekcja 4.7 wymaga rozszerzonych danych raportu
Standardowe obiekty, od których zależy ta konfiguracja	[strony, encje, pola, widoki, raport]
Co musi być ponownie zweryfikowane przy każdym release update	Przykład: Pole nadal poprawnie umieszczone na obu stronach, zdarzenie nadal się wyzwala, przypadki testowe T1 i T2
Co może się zepsuć i jak to zostanie zauważone	[tekst]
Właściciel ponownej weryfikacji po starcie produkcyjnym	[rola po stronie klienta]
Warunek wycofania	[gdy standard pokryje potrzebę, obiekt jest usuwany]

8. Wdrożenie

Pozycja	Opis
Zbudowano w środowisku	[środowisko]
Przeniesiono przez	[pakiet konfiguracji, nazwany i zwersjonowany / kroki ręczne wymienione tutaj]
Środowiska docelowe i kolejność	[test, SAT, produkcja lub środowisko referencyjne]
Kroki po wdrożeniu	[publikacja, zatwierdzenie, synchronizacja, przyznanie dostępu, odświeżenie]
Potrzebny wpis do planu cutover	[Tak / Nie]
Instrukcje krok po kroku do aktualizacji	[ID instrukcji]

9. Zatwierdzenie

Budowa może się zacząć po zatwierdzeniu przez kierownika projektu po stronie klienta. Właściciel procesu potwierdza, że sekcja 3 odpowiada uzgodnionemu sposobowi działania.

Rola	Imię i nazwisko	Decyzja	Data
Właściciel procesu po stronie klienta (logika potwierdzona)	[imię i nazwisko]	[Zatwierdzono / Zatwierdzono z uwagami / Odrzucono]	[YYYY-MM-DD]
Kierownik projektu po stronie klienta	[imię i nazwisko]
Kierownik rozwiązania technicznego (zrecenzowano)	[imię i nazwisko]

Odbiór po teście:

Rola	Imię i nazwisko	Odniesienie do dowodu testowego	Data	Podpis
Właściciel procesu po stronie klienta	[imię i nazwisko]	[link]	[YYYY-MM-DD]

Uwagi i warunki: [tekst]

Niezależny szablon zgodny z metodyką wdrożeniową IFS. Nie jest oficjalnym dokumentem IFS. IFS jest zastrzeżonym znakiem towarowym IFS AB.

Marketplace