Visual Paradigm Desktop | 
Visual Paradigm Online
Tworzenie diagramu przepływu danych (DFD) to istotny krok w analizie systemu. Ilustruje on przepływ danych przez system, definiując sposób przetwarzania, przechowywania i przekazywania informacji. Jednak diagram, który wygląda wizualnie atrakcyjnie, nie musi być funkcjonalnie poprawny. Weryfikacja to kluczowy etap, w którym sprawdzasz, czy diagram poprawnie odzwierciedla wymagania systemu bez błędów logicznych. Ten proces zapewnia spójność przepływów danych, zrównoważenie procesów oraz strukturę wspierającą zamierzony model biznesowy.
Weryfikacja to nie pojedyncza czynność, lecz systematyczny przegląd. Wymaga ona metodycznego podejścia do sprawdzania każdego elementu pod kątem ustalonych zasad. Przestrzegając zorganizowanego procesu przeglądu, eliminujesz niejasności i zapewnicasz, że diagram pełni rolę wiarygodnego projektu w procesie rozwoju oraz komunikacji z zaangażowanymi stronami. Niniejszy przewodnik przedstawia kompleksowe kroki potrzebne do skutecznej weryfikacji Twojego DFD, zapewniając dokładność i spójność na całym etapie projektowania systemu.
Zanim przejdziesz do konkretnych kroków, istotne jest zrozumienie, czego dokonuje weryfikacja w kontekście projektowania systemu. Weryfikacja pyta: „Czy budujemy produkt poprawnie?”. Weryfikacja pyta: „Czy budujemy właściwy produkt?”. W kontekście DFD weryfikacja zamyka lukę między abstrakcyjnymi wymaganiami a konkretnym zachowaniem systemu.
Zweryfikowany DFD zapewnia:
Pominięcie tego etapu często prowadzi do kosztownej pracy nad poprawką w trakcie etapu rozwoju. Problemy takie jak brakujące przepływy danych lub niezdefiniowane magazyny danych są trudne do naprawienia, gdy już zaczyna się pisać kod. Ścisły proces przeglądu zmniejsza te ryzyka na wczesnym etapie.
Zanim rozpoczniesz formalny przegląd, upewnij się, że diagram jest gotowy do szczegółowej analizy. Zaburzony lub źle zorganizowany diagram utrudnia weryfikację. Skorzystaj z poniższej listy kontrolnej, aby przygotować swoją pracę:
Diagram kontekstowy to najwyższy poziom abstrakcji. Pokazuje system jako pojedynczy proces oraz jego interakcje z jednostkami zewnętrznymi. Jest to pierwsza linia obrony w procesie weryfikacji.
Zewnętrzne jednostki reprezentują źródła lub miejsca docelowe danych poza granicami systemu. Upewnij się, że każda pokazana jednostka jest konieczna i dokładnie zdefiniowana. Zadaj następujące pytania:
Jedno proces, który reprezentuje system, musi zawierać całą wewnętrzną logikę. Zweryfikuj, czy żadne przepływy danych nie przekraczają granic bez przechodzenia przez ten proces. Jeśli dane przechodzą z jednej jednostki zewnętrznej do drugiej bez wchodzenia do systemu, nie powinny być pokazywane na diagramie kontekstowym, ponieważ znajdują się poza zakresem.
Przejrzyj każdą strzałkę połączoną z głównym procesem. Każdy przepływ wejściowy musi mieć odpowiadający mu przepływ wyjściowy lub działanie przechowywania. Jeśli przepływ danych wchodzi do systemu, ale żadne dane nie opuszczają go, może to wskazywać na proces „Czarnego dziura”, w którym dane znikają bez powodu.
Diagram DFD poziomu 0 rozdziela pojedynczy proces diagramu kontekstowego na główne podsystemy. Najważniejszym zasadą tutaj jestzrównoważenie. Wejścia i wyjścia procesu nadrzędnego muszą dokładnie odpowiadać wejściom i wyjściom procesów potomnych.
Dla każdego przepływu danych wchodzącego do procesu diagramu kontekstowego musi istnieć odpowiadający mu przepływ danych wchodzący do diagramu poziomu 0. To samo dotyczy wyjść. Jest to znane jako zachowanie danych. Jeśli diagram kontekstowy pokazuje „Zamówienie klienta” wchodzące do systemu, diagram poziomu 0 musi pokazywać „Zamówienie klienta” wchodzące do co najmniej jednego z głównych procesów.
Poziom 0 zwykle zawiera od 3 do 7 procesów. Jeśli masz więcej niż 7, diagram może być zbyt złożony do jednego widoku. Jeśli masz mniej niż 3, może być konieczne dalsze rozłożenie. Upewnij się, że każdy proces jest odrębny i wykonuje jedną funkcję logiczną.
Sprawdź, czy każdy magazyn danych na poziomie 0 jest konieczny. Magazyn danych powinien istnieć tylko wtedy, gdy dane muszą być zachowane do późniejszego użycia. Upewnij się, że przepływy danych do i z magazynów są poprawnie oznaczone. Magazyny danych nie powinny być połączone bezpośrednio z jednostkami zewnętrznymi; wszystkie dane muszą przechodzić przez proces.
Diagramy poziomu N dostarczają dalszych szczegółów dla określonych procesów zidentyfikowanych na poziomie 0. Weryfikacja na tym poziomie skupia się na spójności z procesem nadrzędnym.
Tak jak na poziomie 0, wejścia i wyjścia procesu nadrzędnego muszą odpowiadać łącznie wejściom i wyjściom jego dzieci. Jeśli proces 1.0 na diagramie poziomu 0 pobiera „Dane logowania” i generuje „Token dostępu”, rozkład procesu 1.0 na poziomie 1 również musi przyjmować „Dane logowania” i generować „Token dostępu”.
Upewnij się, że rozkład jest logiczny. Czy diagram potomny wyjaśniajak jak działa proces nadrzędny? Unikaj wprowadzania nowych jednostek zewnętrznych lub magazynów danych w diagramie potomnym, które nie były sugerowane w procesie nadrzędnym. Jeśli wprowadzony jest nowy magazyn danych, musi być uzasadniony wymaganiem zachowania danych.
Etykiety na przepływach danych w diagramach potomnych muszą odpowiadać etykietom w diagramie nadrzędnym tam, gdzie to możliwe. Jeśli przepływ jest doprecyzowany w diagramie potomnym (np. „Dane” staje się „Dane użytkownika”), zmiana ta powinna być spójna z słownikiem danych. Niejasność tutaj prowadzi do zamieszania podczas implementacji.
Istnieją określone anomalie strukturalne, które wskazują na błędy w projektowaniu diagramu DFD. Te typowe wzorce muszą zostać zidentyfikowane i usunięte podczas weryfikacji.
Proces czarnej dziury to taki, który ma wejścia, ale nie ma wyjść. Dane wchodzą do procesu i znikają. Zazwyczaj oznacza to brakujące wyjście lub niekompletną definicję procesu. Każdy proces musi generować jakiś wynik, czy to dane do przechowania, dane do wysłania gdzie indziej, czy wynik decyzji.
Proces cudu to taki, który ma wyjścia, ale nie ma wejść. Tworzy dane z niczego. Jest to logicznie niemożliwe w projektowaniu systemu. Każde wyjście musi być generowane na podstawie danych wejściowych lub wyprowadzone z przechowywanych danych.
Szara dziura występuje, gdy wejścia nie pasują logicznie do wyjść. Na przykład, jeśli wejście to „Adres klienta”, a wyjście to „Dane płatności”, proces wykonuje więcej niż tylko przekształcenie; tworzy dane, które nie mogą zostać wyprowadzone z wejścia. Oznacza to brakujące przepływy danych lub brakujące magazyny danych.
Upewnij się, że przepływy danych nie idą bezpośrednio od zewnętrznej jednostki do magazynu danych. Wszystkie dane wchodzące do magazynu lub wychodzące z niego muszą przechodzić przez proces. Zapewnia to, że zasady integralności danych i logika biznesowa są stosowane przed zapisem.
Użyj tej tabeli jako szybkiego przypomnienia podczas sesji przeglądu. Podsumowuje kluczowe zasady oraz konkretne sprawdzenia wymagane dla każdego elementu.
| Element | Zasada weryfikacji | Typowy błąd |
|---|---|---|
| Proces | Muszą istnieć co najmniej jedno wejście i jedno wyjście | Proces czarnej dziury lub cudu |
| Magazyn danych | Muszą być połączone z procesem, a nie jednostką | Bezpośredni przepływ od jednostki do magazynu |
| Przepływ danych | Muszą być oznaczone frazą rzeczownikową | Oznaczenia czasownikowe lub brakujące oznaczenia |
| Zewnętrzna jednostka | Muszą znajdować się poza granicami systemu | Jednostka wewnątrz granic systemu |
| Spójność | Wejścia i wyjścia rodzica i dziecka muszą się zgadzać | Niezrównoważone przepływy danych |
| Rozkład | Dziecko musi wyjaśnić „jak”, a nie „dlaczego” | Dodawanie logiki poza zakresem |
Weryfikacja to nie tylko sprawdzenie techniczne; jest to narzędzie komunikacji. Po spełnieniu zasad technicznych diagram musi zostać przejrzany przez zainteresowane strony, aby upewnić się, że spełnia potrzeby biznesowe.
Nie przedstawiaj diagramu w izolacji. Przygotuj przewodnik, który wyjaśni przepływ danych. Podaj kontekst, dlaczego istnieją określone magazyny danych i jak procesy ze sobą współdziałają. Upewnij się, że wszystkie zainteresowane strony mają dostęp do słownika danych, aby zrozumieć terminologię.
Zachęć zainteresowane strony do zadawania pytań dotyczących przepływu. Zadawaj konkretne pytania, takie jak:
Zapisz wszystkie opinie i proponowane zmiany. Jeśli zainteresowana strona zaproponuje nowy przepływ danych, zwaliduj go zgodnie z zasadami zrównoważenia, zanim go zaakceptujesz. Aktualizuj diagram i słownik danych jednocześnie, aby zachować synchronizację. Wersjonowanie jest kluczowe; przechowuj zapisy stanu diagramu w każdym cyklu przeglądu.
Weryfikacja rzadko jest zdarzeniem jednorazowym. W miarę zmian wymagań diagram przepływu danych (DFD) musi się zmieniać razem z nimi. Ten rozdział omawia sposób zarządzania zmianami w trakcie cyklu życia projektu.
Gdy zostanie złożona prośba o zmianę, przeanalizuj jej wpływ na całą hierarchię. Jeśli zmienia się proces na poziomie 1, czy ma wpływ na poziom 0? Czy wymaga nowego magazynu danych? Czy wpływa na inne procesy, które dzielą ten sam przepływ danych? Przeprowadzanie analizy wpływu zapobiega błędom kaskadowym.
Zachowaj jasny historię zmian diagramu. Używaj numerów wersji (np. v1.0, v1.1) i dat modyfikacji. Pozwala to zespołowi śledzić, jak ewoluowało projektowanie systemu, oraz cofnąć zmiany, jeśli będzie to konieczne. Choć nie są wymagane konkretne narzędzia, istotne jest stosowanie dyscyplinowanego schematu nazewnictwa plików.
Po wprowadzeniu zmian ponownie uruchom proces weryfikacji. Nie zakładaj, że mała zmiana zachowuje integralność całego diagramu. Ponownie sprawdź zasady zrównoważenia, zasady nazewnictwa i integralność strukturalną. Mała zmiana może czasem naruszyć równowagę wcześniej zwalidowanego diagramu.
Słownik danych jest fundamentem Twojego diagramu przepływu danych (DFD). Definiuje strukturę każdego elementu danych. Weryfikacja musi obejmować nie tylko wizualny diagram, ale także definicje tekstowe.
Upewnij się, że etykiety przepływu danych na diagramie dokładnie odpowiadają wpisom w słowniku. Jeśli diagram mówi „ID faktury”, a słownik mówi „Identyfikator faktury”, taka niezgodność może spowodować zamieszanie podczas projektowania bazy danych. Ujednolit terminologię we wszystkich dokumentach.
Sprawdź, czy każdy magazyn danych ma zdefiniowaną strukturę w słowniku. Wypisz atrybuty, typy danych i ograniczenia kluczy. Jeśli magazyn danych jest odwoływany w DFD, ale nie ma wpisu w słowniku, projekt jest niekompletny. Taka luka często prowadzi do błędów w bazie danych w przyszłości.
Zwaliduj, czy domniemane typy danych na diagramie odpowiadają zasadom biznesowym. Na przykład, jeśli przepływ danych reprezentuje „Data urodzenia”, nie powinien być traktowany jako ciąg znaków w słowniku. Powinien mieć format daty. Taka szczegółowość zapewnia, że implementacja techniczna będzie zgodna z projektem koncepcyjnym.
Nawet doświadczeni analitycy napotykają konkretne pułapki podczas procesu weryfikacji. Znajomość tych typowych pułapek pomaga skuteczniej przeprowadzać przegląd.
Po zakończeniu weryfikacji dokumentacja musi zostać finalnie przygotowana do przekazania zespołowi programistycznemu. Obejmuje to złożenie schematów, słownika danych oraz raportu weryfikacji.
Zbierz wszystkie schematy poziomu 0, schematy poziomu N oraz schemat kontekstowy w jednym pakiecie. Upewnij się, że hierarchia jest jasno oznaczona, aby deweloperzy mogli śledzić dekompozycję. Dołącz słownik danych jako dokument towarzyszący.
Stwórz podsumowanie procesu weryfikacji. Wypisz wszelkie problemy znalezione podczas przeglądu oraz sposób ich rozwiązania. Ten dokument stanowi dowód, że projekt został przejrzany. Stanowi również kontekst dla przyszłych utrzymujących, którzy nie byli częścią początkowego przeglądu.
Zdefiniuj proces przekazania zweryfikowanych schematów przepływu danych (DFD). Powinien obejmować spotkanie, na którym projekt zostanie wyjaśniony zespołowi programistycznemu. Rozwiąż wszelkie pytania dotyczące niejasnych przepływów lub skomplikowanych magazynów danych. Upewnij się, że zespół rozumie, że DFD jest źródłem prawdy dla wymagań danych.
Praca nie kończy się na weryfikacji. Schemat musi pozostawać dokładny w miarę ewolucji systemu. Ustanów proces zarządzania zmianami dla przyszłych zmian.
Przestrzegając tych kroków weryfikacji, zapewnisz, że Twoje schematy przepływu danych są wytrzymałe, dokładne i użyteczne przez cały cykl życia systemu. Ta dyscyplina zmniejsza niejasności, zapobiega kosztownym błędom i tworzy solidną podstawę dla sukcesu w tworzeniu systemu.