Słownik analityka biznesowego

DPIA (Data Protection Impact Assessment, ocena skutków dla ochrony danych) to wymagana przez art.

Dane testowe to dane przygotowane specjalnie do weryfikacji systemu: na tyle realistyczne, by testy odzwierciedlały produkcję, na tyle kompletne, by pokryć przypadki brzegowe, i na tyle bezpieczne, by nie łamać prawa.

Dashboard (pulpit, kokpit menedżerski) to ekran zbierający najważniejsze wskaźniki w jednym widoku: zwykle interaktywny (filtry, drill-down do szczegółów) i odświeżany automatycznie z danych źródłowych.

Data governance (ład danych) to system zarządzania danymi jako zasobem organizacji: kto jest właścicielem których danych, jakie obowiązują definicje pojęć i wskaźników, jakie standardy jakości, kto i na jakich zasadach ma dostęp.

Data Lake to takie ogromne, cyfrowe jezioro, w którym gromadzisz wszystkie dane Twojej firmy w surowej, nieprzetworzonej formie. Używasz go, gdy chcesz analizować dane z różnych źródeł (np. media społecznościowe, dane sprzedażowe, logi systemowe) i nie wiesz jeszcze dokładnie, jakie informacje z nich wyciągnąć. Wyobraź sobie, że wrzucasz do tego jeziora wszystko jak leci, a dopiero później, gdy wiesz czego szukasz, wyławiasz i analizujesz potrzebne fragmenty.

Data mining (eksploracja danych) to odkrywanie nieoczywistych wzorców w dużych zbiorach danych metodami statystyki i uczenia maszynowego.

Data quality (jakość danych) to stopień, w jakim dane nadają się do zamierzonego użycia.

Data warehouse (hurtownia danych) to centralna baza analityczna, która integruje dane z wielu systemów źródłowych i jest zoptymalizowana pod raportowanie oraz analizę - w odróżnieniu od baz operacyjnych (OLTP), zoptymalizowanych pod szybkie

Defect (defekt, wada, potocznie „bug") to niezgodność działania systemu z wymaganiami lub uzasadnionymi oczekiwaniami użytkownika.

Definition of Done to lista kryteriów, które muszą być spełnione, żeby uznać daną pracę za zakończoną. Używamy tego, żeby wszyscy rozumieli tak samo, co oznacza "zrobione" i uniknąć sytuacji, w której ktoś myśli, że praca jest skończona, a w rzeczywistości wymaga jeszcze poprawek. Na przykład, dla zadania "napisanie posta na bloga", Definition of Done może zawierać: "tekst napisany, zredagowany, zaakceptowany przez klienta, opublikowany na stronie".

Definition of Ready (DoR) to lista kontrolna, która określa, czy wymaganie (np. zadanie do zrobienia) jest wystarczająco jasne i szczegółowe, żeby zespół mógł je zacząć realizować. Używamy jej przed rozpoczęciem pracy nad wymaganiem, żeby uniknąć nieporozumień i przestojów. Na przykład, wymaganie "Zrobić przycisk" nie jest gotowe, ale "Zrobić zielony przycisk 'Kup teraz' na stronie produktu, który przenosi do koszyka" już bardziej.

Design Sprint to taki intensywny, kilkudniowy warsztat, który pomaga szybko wymyślić i przetestować nowe pomysły na produkt lub rozwiązanie problemu. Używa się go, gdy potrzebujesz w krótkim czasie zweryfikować, czy twój pomysł ma szansę powodzenia, zanim zainwestujesz w niego dużo czasu i pieniędzy, np. chcesz stworzyć nową aplikację do zamawiania jedzenia i w Design Sprincie sprawdzasz, czy użytkownicy w ogóle by z niej korzystali.

Design Thinking to sposób na rozwiązywanie problemów, stawiający użytkownika w centrum uwagi. Chodzi o to, żeby zrozumieć potrzeby ludzi i na tej podstawie wymyślić innowacyjne rozwiązania. Na przykład, zamiast projektować nowy telefon, który ma więcej funkcji, Design Thinking skupiłoby się na tym, jak ludzie naprawdę używają telefonów i co im sprawia trudności, żeby stworzyć coś naprawdę użytecznego.

DevOps to sposób pracy, który łączy programistów (Dev) i osoby odpowiedzialne za działanie systemów (Ops), żeby szybciej i sprawniej tworzyć i wdrażać oprogramowanie. Wyobraź sobie, że programista pisze program, a zamiast czekać tygodniami na jego uruchomienie, DevOps pozwala mu od razu go przetestować i udostępnić użytkownikom. Używamy tego, gdy chcemy szybko reagować na potrzeby klientów i ciągle ulepszać nasze programy.

Diagram ERD (Entity-Relationship Diagram, diagram związków encji) to model danych pokazujący encje (rzeczy, o których system przechowuje informacje - pacjent, wizyta, lekarz), ich atrybuty oraz relacje między nimi wraz z licznościami: jeden

Diagram Gantta to wykres harmonogramu: zadania jako poziome paski na osi czasu, z widoczną długością trwania, zależnościami między zadaniami (koniec-początek i inne) oraz kamieniami milowymi.

Diagram Ishikawy (diagram rybiej ości, diagram przyczynowo-skutkowy) to technika porządkowania potencjalnych przyczyn problemu.

Diagram Venna (Venn diagram) to graficzne przedstawienie zbiorów jako nakładających się okręgów - części wspólne pokazują elementy należące do kilku zbiorów naraz.

Diagram aktywności (activity diagram) to diagram UML pokazujący przepływ działań w procesie lub algorytmie: akcje, decyzje (romby), przepływy równoległe (fork/join) i tory odpowiedzialności (swimlanes).

Diagram klas to taki schemat, który pokazuje, z czego składają się różne elementy systemu (np. programu komputerowego) i jak one się ze sobą łączą. Używamy go, żeby łatwiej zrozumieć i zaplanować, jak system ma działać - na przykład, jak klient w sklepie internetowym zamawia produkt. Wyobraź sobie, że masz diagram klas dla sklepu internetowego. Mógłby pokazywać, że "Klient" ma atrybuty takie jak "imię" i "adres", może "składa" "Zamówienie", a "Zamówienie" zawiera "Produkty". To pomaga zobaczyć, jak te elementy są powiązane.

Diagram komponentów (component diagram) to diagram UML pokazujący logiczną budowę systemu: komponenty oprogramowania i interfejsy, którymi się komunikują - dostarczane (provided, „lizak") i wymagane (required, „gniazdko").

Diagram kontekstowy (context diagram) przedstawia system jako jedną „czarną skrzynkę" w środku i wszystkie zewnętrzne podmioty - ludzi, systemy, organizacje - które wymieniają z nim dane.

Diagram przepływu (flowchart) to najprostsza notacja procesowa: prostokąty jako kroki, romby jako decyzje, strzałki jako kolejność.

Diagram przepływu danych (DFD) to taki rysunek, który pokazuje, jak informacje wędrują przez system, np. w firmie. Używa się go, żeby zrozumieć i pokazać, co się dzieje z danymi od momentu, gdy wchodzą do systemu, aż do momentu, gdy z niego wychodzą. Na przykład, DFD może pokazywać, jak zamówienie klienta przechodzi przez różne działy w sklepie internetowym: od złożenia zamówienia, przez jego realizację, aż po wysyłkę.

Diagram przypadków użycia (use case diagram) to diagram UML pokazujący, CO system robi dla swoich użytkowników: aktorzy (ludziki), przypadki użycia (elipsy) i relacje między nimi, w tym «include» i «extend».

Diagram sekwencji (sequence diagram) to diagram UML pokazujący interakcje między obiektami lub systemami w czasie: pionowe linie życia, poziome strzałki komunikatów, kolejność czytana z góry na dół.

Diagram stanów to graficzny sposób pokazania, jak obiekt (np. produkt, proces, system) zmienia swoje stany w odpowiedzi na różne zdarzenia. Używamy go, żeby zrozumieć i zaplanować, jak coś powinno działać w różnych sytuacjach. Na przykład, automat z napojami może być w stanie "oczekiwania", potem "wybierania napoju", a na koniec "wydawania napoju" - diagram stanów pokaże, jak przechodzi między tymi stanami po wrzuceniu monety i naciśnięciu przycisku.

Diagram wdrożenia (deployment diagram) to diagram UML pokazujący fizyczną architekturę systemu: węzły (serwery, urządzenia, środowiska chmurowe), rozmieszczone na nich artefakty oprogramowania i połączenia sieciowe między nimi.

Disaster Recovery (DR, odtwarzanie po awarii) to zestaw procedur, ról i infrastruktury, które pozwalają przywrócić działanie systemów po poważnej awarii: pożarze serwerowni, ataku ransomware, utracie centrum danych.

Domain-Driven Design (DDD) to sposób tworzenia oprogramowania, który kładzie nacisk na zrozumienie i modelowanie najważniejszego obszaru działania firmy, czyli "domeny". Używamy go, gdy mamy złożony problem biznesowy, żeby oprogramowanie idealnie pasowało do potrzeb użytkowników i było łatwiejsze w rozwoju. Na przykład, w systemie dla szpitala, domeną jest opieka nad pacjentem, więc modelujemy pojęcia takie jak "pacjent", "wizyta", "lekarz" tak, jak rozumieją je lekarze i pielęgniarki.

Drzewo decyzyjne (decision tree) to diagram przedstawiający rozgałęziającą się logikę decyzji: z węzła wychodzi pytanie, gałęzie to możliwe odpowiedzi, liście to wyniki końcowe.