Pytania pomocnicze - INF.04

UX to doświadczenie użytkownika podczas korzystania z aplikacji. Obejmuje wygodę, zrozumiałość, szybkość wykonania zadania i ogólne odczucia użytkownika.

Czytelna czcionka ułatwia odbiór informacji i zmniejsza ryzyko błędów. Użytkownik nie musi się domyślać, co znajduje się na ekranie.

Oznacza takie rozmieszczenie przycisków, pól i menu, aby użytkownik łatwo rozumiał, co może zrobić i gdzie znaleźć potrzebną funkcję.

Użytkownik traci czas na szukanie funkcji i może popełniać błędy. Interfejs staje się mniej przewidywalny i mniej wygodny.

Daje użytkownikowi poczucie kontroli i bezpieczeństwa. Jeśli popełni błąd, może go łatwo naprawić.

Nie. Kolory powinny pomagać odróżniać elementy, sygnalizować ważność i prowadzić uwagę użytkownika. Jeden kolor może utrudnić orientację w interfejsie.

UI dotyczy wyglądu i elementów interfejsu, np. przycisków, menu i formularzy. UX dotyczy całego doświadczenia użytkownika podczas korzystania z aplikacji.

Ponieważ różne struktury danych mają różny czas dostępu, wyszukiwania, dodawania i usuwania elementów. Źle dobrana struktura może znacząco spowolnić program.

Oznacza koszt wykonania operacji na danych, np. ile czasu lub pamięci wymaga wyszukanie, posortowanie albo zapisanie elementu. Często opisuje się ją za pomocą notacji Big O.

Należy sprawdzić, jak często aplikacja będzie dodawać, usuwać, wyszukiwać, sortować i aktualizować dane. Najczęstsze operacje powinny być możliwie szybkie.

Mapa jest lepsza, gdy dane mają być szybko wyszukiwane po kluczu, np. identyfikatorze użytkownika. Lista sprawdza się lepiej przy prostym przechowywaniu elementów w kolejności.

Nie. Język programowania może narzucać dostępne typy i biblioteki, ale ważniejsze są wymagania aplikacji, rodzaj danych, operacje na danych oraz oczekiwana wydajność.

Niektóre struktury danych przyspieszają operacje, ale wymagają więcej pamięci. W aplikacjach mobilnych, wbudowanych lub pracujących na dużych zbiorach danych ma to duże znaczenie.

Wymagania wskazują, jakie dane będą przechowywane i jak będą używane. Na tej podstawie można dobrać strukturę, która najlepiej obsłuży typowe operacje aplikacji.

Architektura klient-serwer polega na podziale aplikacji na klienta, który wysyła żądania, oraz serwer, który je obsługuje i zwraca odpowiedzi. Klient zwykle odpowiada za interfejs użytkownika, a serwer za logikę biznesową, dane i bezpieczeństwo.

Serwer jest centralnym miejscem przetwarzania, ponieważ ma dostęp do bazy danych, logiki aplikacji i mechanizmów bezpieczeństwa. Ułatwia to kontrolę danych, aktualizacje oraz zarządzanie wieloma klientami.

Klient odpowiada głównie za komunikację z użytkownikiem, prezentację danych i wysyłanie żądań do serwera. Przykładem klienta może być przeglądarka internetowa, aplikacja mobilna lub desktopowa.

Serwer odbiera żądania od klientów, wykonuje operacje, przetwarza dane i odsyła wyniki. Może również obsługiwać uwierzytelnianie, autoryzację oraz dostęp do bazy danych.

W architekturze klient-serwer aplikacja wymaga komunikacji z serwerem, który wykonuje część zadań lub udostępnia dane. Aplikacja offline działa lokalnie i nie potrzebuje stałego połączenia z serwerem.

Podział na klienta i serwer jest podstawową cechą tej architektury. Bez tego podziału aplikacja nie realizuje modelu, w którym jedna strona wysyła żądania, a druga je obsługuje.

Ponieważ aplikacja jest podzielona na niezależne części. Zmianę można wprowadzić w jednym module bez dużego ryzyka uszkodzenia całego systemu.

Moduł to wydzielona część programu odpowiedzialna za konkretną funkcję, np. logowanie, płatności lub raportowanie.

Brak specyfikacji utrudnia ustalenie, co aplikacja ma robić i jak ma być zbudowana. Prowadzi to do chaosu, błędów i trudniejszych zmian.

Dokumentacja pomaga zrozumieć działanie aplikacji i decyzje projektowe. Dzięki temu łatwiej wprowadzać zmiany oraz poprawiać błędy.

Wygląd aplikacji jest ważny, ale nie zastępuje poprawnej struktury kodu. Aplikacja może wyglądać dobrze, a jednocześnie być trudna w rozbudowie.

Moduły można testować osobno, co ułatwia wykrywanie błędów. Zmiana w jednym module wymaga zwykle przetestowania mniejszej części systemu.

Ponieważ urządzenia różnią się rozmiarem ekranu, sposobem obsługi i możliwościami technicznymi. Dostosowany interfejs poprawia wygodę, czytelność i efektywność pracy użytkownika.

Nie. Aplikację nadal trzeba testować na różnych urządzeniach, systemach i rozdzielczościach, ponieważ błędy UI mogą występować tylko w konkretnych warunkach.

Aplikacja cross-platform może działać na wielu systemach lub urządzeniach. Responsywny interfejs oznacza, że wygląd i układ aplikacji dostosowują się do warunków użycia.

Najczęściej dostosowuje się menu, przyciski, formularze, rozmiary czcionek, obrazy oraz układ treści. Ważne jest też zapewnienie wygodnej obsługi dotykiem.

Dostosowanie interfejsu dotyczy przede wszystkim jakości korzystania z aplikacji, a nie samej organizacji kodu. Kod może być wspólny częściowo, ale celem jest wygoda użytkownika na danej platformie.

Użytkownik może mieć problemy z odczytaniem treści, klikaniem przycisków lub korzystaniem z formularzy. Może to prowadzić do błędów, frustracji i rezygnacji z aplikacji.

Ponieważ późniejsze dodawanie zabezpieczeń jest trudniejsze, droższe i często mniej skuteczne. Projekt powinien od początku uwzględniać ochronę danych, kontrolę dostępu i bezpieczne przetwarzanie informacji.

Szczególnej ochrony wymagają m.in. dane osobowe, dane logowania, adresy e-mail, numery telefonów, dane finansowe oraz informacje medyczne. Ich wyciek może naruszać prywatność i przepisy prawa.

Uwierzytelnianie sprawdza, kim jest użytkownik, np. przez login i hasło. Autoryzacja określa, do jakich funkcji i danych ten użytkownik ma dostęp.

W przypadku wycieku bazy atakujący od razu poznałby hasła użytkowników. Hasła powinny być przechowywane jako bezpieczne skróty z użyciem soli i odpowiedniego algorytmu.

HTTPS szyfruje komunikację między przeglądarką a serwerem. Dzięki temu dane, np. login i hasło, nie powinny być możliwe do łatwego podsłuchania w sieci.

Testowanie pozwala wykryć błędy, luki i nieprawidłową kontrolę dostępu przed wdrożeniem aplikacji. Pominięcie testów zwiększa ryzyko wycieku lub uszkodzenia danych.

Sam wygląd interfejsu nie zabezpiecza danych. Może poprawiać użyteczność, ale bezpieczeństwo zależy od mechanizmów takich jak szyfrowanie, walidacja, kontrola dostępu i aktualizacje.

Dokumentacja porządkuje ustalenia i zmniejsza ryzyko nieporozumień. Programiści otrzymują jasny opis funkcji, ograniczeń technicznych i oczekiwanego działania systemu.

Wymagania funkcjonalne opisują, co system ma robić, np. logowanie lub generowanie raportów. Wymagania techniczne opisują, jakich technologii, środowisk, integracji lub ograniczeń należy użyć.

Makiety pokazują wygląd interfejsu, ale często nie opisują logiki działania, walidacji danych, obsługi błędów ani wymagań technicznych. Dlatego powinny być uzupełnione opisem funkcji.

Analiza wymagań pozwala zrozumieć potrzeby klienta, uporządkować je i wykryć braki lub sprzeczności. Dopiero na tej podstawie można przygotować użyteczną dokumentację dla zespołu.

Jednoznaczne wymaganie nie pozostawia miejsca na różne interpretacje. Testowalne wymaganie pozwala sprawdzić, czy dana funkcja została wykonana poprawnie.

Programiści potrzebują opisu funkcji, danych wejściowych i wyjściowych, reguł biznesowych, obsługi błędów, ograniczeń technicznych oraz integracji z innymi systemami.

Programiści nie zawsze znają pełny kontekst biznesowy klienta. Potrzebna jest komunikacja z klientem, analiza potrzeb i zapisanie ustaleń w formie dokumentu.

Cel projektu informatycznego określa, jaki problem ma zostać rozwiązany i jaki rezultat ma zostać osiągnięty. Powinien wskazywać sens realizacji projektu, a nie tylko listę zadań.

Bez jasnego określenia problemu zespół może tworzyć rozwiązanie, które nie odpowiada rzeczywistym potrzebom użytkownika lub klienta. Problem wyznacza kierunek dalszej analizy i projektowania.

Cel projektu mówi, co i po co ma zostać osiągnięte. Harmonogram określa, kiedy i w jakiej kolejności będą realizowane poszczególne działania.

Nie. Wybór technologii jest środkiem do realizacji celu, np. wyborem narzędzi, języków programowania lub frameworków potrzebnych do wykonania rozwiązania.

Analiza wymagań pomaga doprecyzować, czego oczekuje klient lub użytkownik. Dzięki niej można sprawdzić, czy planowane rozwiązanie rzeczywiście realizuje cel projektu.

Ocena postępów służy kontroli wykonywania prac w trakcie projektu. Cel projektu określa natomiast oczekiwany końcowy efekt i powód realizacji projektu.

Faza analizy polega na poznaniu potrzeb użytkownika i opisaniu wymagań wobec systemu. Jej celem jest ustalenie, co aplikacja ma robić.

Wdrażanie polega na uruchomieniu gotowego systemu w środowisku użytkownika. Wymagania powinny być znane dużo wcześniej, przed projektowaniem i programowaniem.

Planowanie dotyczy organizacji projektu, np. harmonogramu, kosztów i zasobów. Analiza dotyczy ustalenia potrzeb użytkownika i funkcji systemu.

Mogą powstać specyfikacja wymagań, opis przypadków użycia, lista funkcji systemu, diagramy procesów lub makiety interfejsu.

Jeśli wymagania zostaną źle rozpoznane, zespół może stworzyć system niezgodny z potrzebami użytkownika. Poprawki na późniejszych etapach są zwykle droższe i trudniejsze.

Użytkownik lub klient dostarcza informacji o swoich potrzebach, problemach i oczekiwaniach. Bez jego udziału trudno poprawnie określić wymagania systemu.

Pozwalają przypisać właściwe osoby do odpowiednich zadań. Dzięki temu praca jest efektywniejsza, a ryzyko błędów i opóźnień mniejsze.

Kompetencje techniczne dotyczą wiedzy specjalistycznej, np. programowania lub testowania. Kompetencje miękkie dotyczą współpracy, komunikacji i odpowiedzialności.

Doświadczenie pomaga szybciej rozwiązywać problemy i przewidywać ryzyka. Osoby bardziej doświadczone mogą też wspierać mniej zaawansowanych członków zespołu.

Nie. Budżet jest ważny, ale nie zastępuje analizy kompetencji, doświadczenia i dostępności członków zespołu.

Może dojść do opóźnień, błędów technicznych, obniżenia jakości produktu i konieczności poprawek.

Należy uwzględnić umiejętności, doświadczenie, dostępność, zakres odpowiedzialności oraz stopień trudności danego zadania.