Test INF.04 — zestaw 3

Dlaczego tak

Sortowanie przez scalanie zawsze dzieli tablicę na połowy i scala je w czasie liniowym, więc wykonuje ok. n log n operacji dla każdych danych. Sortowanie szybkie ma średnio złożoność O(n log n), ale przy niekorzystnym wyborze elementu osiowego, np. dla danych już posortowanych, spada do O(n²). Sortowanie bąbelkowe i przez wstawianie mają złożoność pesymistyczną O(n²).

Dlaczego tak

W pierwszym przejściu porównuje się kolejne pary: 5 > 1 — zamiana, 5 > 4 — zamiana, 5 > 2 — zamiana, 5 < 8 — bez zamiany. Liczba 5 „wypływa” w prawo aż do 8, a tablica ma postać [1, 4, 2, 5, 8]. Układ [1, 5, 4, 2, 8] to wynik pierwszego kroku sortowania przez wybieranie, które zamienia tylko najmniejszy element z pierwszym, a w pełni posortowana tablica wymaga jeszcze kolejnego przejścia.

Dlaczego tak

Każde porównanie z elementem środkowym zmniejsza przeszukiwany zakres o połowę, więc po k porównaniach zostaje ok. 1000 / 2^k elementów. Ponieważ 2¹⁰ = 1024 > 1000, wystarczy co najwyżej 10 porównań. Wartość 1000 to pesymistyczna liczba porównań wyszukiwania liniowego, a 500 — jego średnia, które dotyczą tablic nieposortowanych.

Dlaczego tak

Wykres spalania zestawia ilość pracy pozostałej do końca sprintu, np. w punktach historyjek, z linią idealnego postępu; jeśli rzeczywista linia leży wyraźnie nad idealną, zespół nie zdąży bez zmian w zakresie. Tablica Kanban pokazuje aktualny status zadań, ale nie ich przebieg w czasie. Backlog jest uporządkowaną listą wszystkich wymagań produktu i nie mierzy postępu sprintu.

Dlaczego tak

Czas trwania projektu wyznacza najdłuższa ścieżka zależności, czyli ścieżka krytyczna: A → B → D = 3 + 4 + 3 = 10 dni. Ścieżka A → C → D trwa 8 dni, więc zadanie C ma 2 dni zapasu i jego opóźnienie o 1–2 dni nie przesunie końca projektu. Wynik 12 to suma wszystkich zadań, która zakłada, że B i C wykonuje się po kolei, choć mogą przebiegać równolegle.

Dlaczego tak

W Jira hierarchia elementów pracy to epik, pod nim historyjki, zadania i błędy, a na najniższym poziomie podzadania. Epik opisuje większą funkcję, np. „Płatności w aplikacji”, realizowaną w kilku sprintach. Sprint nie jest elementem pracy, tylko ramą czasową (zwykle 1–4 tygodnie), w której zespół wykonuje wybrane zadania, a podzadanie dzieli pojedyncze zadanie na mniejsze kroki.

Dlaczego tak

Polecenie git commit zapisuje zmiany tylko w lokalnym repozytorium na komputerze programisty. Aby wysłać zatwierdzenia do repozytorium zdalnego, trzeba wykonać git push. Polecenia git pull i git fetch działają w przeciwną stronę — pobierają zmiany z serwera do repozytorium lokalnego, a git merge łączy gałęzie lokalnie i niczego nie wysyła.

Dlaczego tak

Wymagania funkcjonalne opisują, co system robi — jakie operacje udostępnia i komu — dlatego przeglądanie, ograniczenie widoku do własnych wyników i eksport do PDF są funkcjonalne. Wymaganie niefunkcjonalne określa, jak dobrze system ma działać: wydajność, dostępność, bezpieczeństwo, użyteczność. Czas ładowania ekranu poniżej 2 s jest wymaganiem wydajnościowym, które projektant musi uwzględnić w architekturze, choć nie dodaje żadnej nowej funkcji.

Dlaczego tak

Specyfikacja techniczna zamienia ogólne życzenie klienta na wymagania jednoznaczne i sprawdzalne: wiadomo, po jakich polach się wyszukuje, jak traktowana jest wielkość liter i jaki czas odpowiedzi trzeba osiągnąć, więc tester może napisać do tego przypadki testowe. Określenia „intuicyjna”, „łatwo i szybko” powtarzają tylko słowa klienta i każdy programista zrozumie je inaczej. Pozostawienie decyzji programiście przenosi ryzyko na koniec projektu, gdy klient odrzuci rozwiązanie.

Dlaczego tak

Przyciski opcji połączone w grupę pozwalają zaznaczyć tylko jedną pozycję — wybranie kolejnej automatycznie odznacza poprzednią, a wszystkie możliwości są cały czas widoczne. Pola wyboru działają niezależnie od siebie, więc użytkownik mógłby zaznaczyć dwa lub trzy poziomy naraz. Pole tekstowe wymusza wpisywanie i nie ogranicza odpowiedzi do trzech wartości, a pasek postępu jedynie pokazuje stan operacji i nie przyjmuje danych.

Dlaczego tak

Dobry projekt formularza mówi użytkownikowi, co jest źle i jak to naprawić, w miejscu, którego błąd dotyczy, np. „Hasło musi mieć co najmniej 12 znaków”. Sygnalizacja samym kolorem nie dotrze do osoby z daltonizmem ani do użytkownika czytnika ekranu i nie wyjaśnia przyczyny błędu. Ogólne okno „Błąd” też nie wskazuje pola ani przyczyny, a czyszczenie formularza zmusza do ponownego wpisywania wszystkich danych.

Dlaczego tak

Palec jest znacznie mniej precyzyjny niż kursor myszy, dlatego wytyczne Material Design zalecają obszar dotyku co najmniej 48 × 48 dp, a wytyczne Apple — 44 × 44 pt, z odstępami między elementami. Podpowiedzi po najechaniu kursorem nie działają na ekranie dotykowym, bo nie ma tam stanu „najechania”. Skróty klawiaturowe nie pomogą na telefonie bez fizycznej klawiatury, a mniejsze przyciski tylko zwiększą liczbę pomyłek.

Dlaczego tak

Paradygmat obiektowy łączy dane i operacje na nich w klasy: obiekt Ksiazka przechowuje własny stan (tytuł, dostępność), a metody, np. wypozycz(), zmieniają go w kontrolowany sposób, dzięki hermetyzacji niewidoczny z zewnątrz. Rozbicie funkcji na mniejsze to nadal programowanie strukturalne, bo dane pozostają oddzielone od kodu i dostępne dla każdego. Zmienne globalne są wręcz przeciwieństwem hermetyzacji.

Dlaczego tak

Klient widzi stan sprzed chwili, a w tym czasie inna osoba mogła już zarezerwować miejsce, dlatego o dostępności rozstrzyga serwer, sprawdzając i zapisując rezerwację niepodzielnie, w jednej transakcji. Serwer jest też jedynym miejscem, któremu można ufać, bo kod klienta użytkownik może zmodyfikować i wysłać dowolne żądanie. Kontrola w przeglądarce poprawia wygodę, ale nie zastępuje walidacji po stronie serwera.

Dlaczego tak

Kolejka priorytetowa zwraca zawsze element o najwyższym priorytecie, a przy równym priorytecie — np. z numerem przybycia jako drugim kryterium — ten, który czeka najdłużej. Zwykła kolejka FIFO zachowa kolejność przybycia, ale nie przepuści pacjenta pilnego. Stos obsłużyłby jako pierwszego pacjenta, który przyszedł ostatni, a zbiór nie przechowuje żadnej kolejności.

Dlaczego tak

Relacja «include» oznacza, że przypadek bazowy zawsze wykorzystuje zachowanie przypadku dołączanego — tu złożenie zamówienia za każdym razem obejmuje logowanie. Relacja «extend» opisuje zachowanie opcjonalne, wykonywane tylko w określonych warunkach, np. „Użyj kodu rabatowego”. Generalizacja łączy przypadek ogólny z jego szczególną odmianą, a asocjacja łączy aktora z przypadkiem użycia, a nie dwa przypadki ze sobą.

Dlaczego tak

Funkcje bcrypt i Argon2 są celowo wolne i jednokierunkowe, a losowa sól dla każdego użytkownika sprawia, że identyczne hasła mają różne skróty i nie da się użyć gotowych tablic tęczowych. Szyfrowanie AES jest odwracalne: kto zdobędzie bazę i kod z kluczem, odczyta wszystkie hasła. MD5 bez soli jest tak szybki, że łamanie słabych haseł z wycieku trwa minuty.

Dlaczego tak

Cel SMART mówi, co dokładnie ma powstać, po czym poznać sukces i do kiedy: tu jest konkretny produkt, mierzalny wskaźnik 500 klientów i termin 30 czerwca. Sformułowanie „nowoczesna aplikacja poprawiająca wizerunek” nie daje się zmierzyć ani rozliczyć. „Najlepsza na rynku” jest nieosiągalna i niemierzalna, a cel bez terminu — określony „gdy zespół znajdzie czas” — nie pozwala zaplanować harmonogramu.

Dlaczego tak

Najpierw trzeba ustalić, czego potrzebuje klient (analiza wymagań), następnie zaplanować, jak to zbudować (projekt architektury, danych i interfejsu), potem napisać kod, sprawdzić go testami i dopiero przetestowany system wdrożyć u klienta, po czym następuje utrzymanie. Projektowanie przed analizą wymagań oznacza projektowanie czegoś, czego zakresu jeszcze nie znamy. Wdrożenie przed testowaniem przenosi wykrywanie błędów na użytkowników.

Dlaczego tak

Etap utrzymania zaczyna się po przekazaniu systemu do użytku i obejmuje usuwanie błędów wykrytych w eksploatacji, dostosowywanie do zmian środowiska i drobne usprawnienia; często jest najdłuższym i najdroższym etapem cyklu życia. Testowanie odbywa się przed wydaniem, więc nie dotyczy programu używanego od pół roku. Wdrożenie to jednorazowa instalacja i uruchomienie systemu u klienta wraz ze szkoleniem użytkowników.

Dlaczego tak

Zespół trzech osób pracujących po 8 godzin daje 3 · 8 = 24 osobogodziny dziennie, więc 120 / 24 = 5 dni roboczych. Wynik 15 otrzymuje się, dzieląc 120 tylko przez 8, czyli zakładając, że pracuje jeden programista, a 40 — dzieląc 120 tylko przez 3, jakby każdy pracował jedną godzinę dziennie. W praktyce do takiego wyniku dolicza się zapas na komunikację w zespole i nieprzewidziane problemy.

Dlaczego tak

Priorytetyzacja, np. metodą MoSCoW, wyznacza funkcje niezbędne do działania produktu; z nich buduje się minimalną wersję (MVP), którą klient może wcześnie używać i ocenić, a kolejne wydania dodają resztę. Jedno wydanie po trzech miesiącach daje klientowi wartość dopiero na końcu i odkłada wykrycie nieporozumień. Kolejność według łatwości technicznej może zostawić na koniec funkcje, bez których aplikacja jest bezużyteczna.

Dlaczego tak

Limit WIP (work in progress) ogranicza liczbę zadań wykonywanych równocześnie, aby praca płynęła do końca, a nie gromadziła się w połowie. Gdy limit jest osiągnięty, Kanban zaleca „kończyć, zanim się zacznie”: pomóc przy zadaniach w toku, np. w przeglądzie kodu lub testach, albo usunąć blokadę. Doraźne podnoszenie limitu lub praca poza tablicą zespołu ukrywa wąskie gardło, które limit miał właśnie ujawnić.

Dlaczego tak

Model kaskadowy sprawdza się, gdy wymagania są stabilne i znane z góry, a zamawiający oczekuje sekwencji etapów zakończonych odbiorem i kompletnej dokumentacji. Scrum i Kanban zakładają częste zmiany priorytetów i stopniowe odkrywanie wymagań we współpracy z klientem, więc ich zalety się tu nie ujawnią. Model prototypowy służy do wyjaśniania niejasnych wymagań, a w tym projekcie są one już ostatecznie ustalone.

Dlaczego tak

Gałęzie funkcji pozwalają każdemu pracować niezależnie, a pull request przed scaleniem z gałęzią główną daje okazję do przeglądu kodu, uruchomienia testów i rozwiązania konfliktów w kontrolowany sposób. Scalanie ręczne raz w miesiącu prowadzi do ogromnych konfliktów i utraty zmian, bo kopie mocno się rozjeżdżają. Ograniczanie godzin commitów lub praca jednej osoby marnuje czas zespołu i nie rozwiązuje problemu.

Dlaczego tak

Zapas czasu to okres, o jaki zadanie może się opóźnić bez przesunięcia terminu końcowego projektu. Opóźnienie o 2 dni mieści się w 3-dniowym zapasie, więc termin się nie zmienia, ale zapas zmniejsza się do 1 dnia i kolejne opóźnienie będzie groźniejsze. Projekt opóźniłby się o 2 dni tylko wtedy, gdyby zadanie leżało na ścieżce krytycznej, czyli miało zapas równy zero.

Dlaczego tak

We wzorcu Obserwator obiekt obserwowany przechowuje listę subskrybentów zgodnych ze wspólnym interfejsem i po zmianie stanu wywołuje u każdego metodę powiadamiającą, nie znając ich konkretnych klas. Nowy rodzaj odbiorcy dodaje się bez zmiany klasy kursu. Fasada upraszcza dostęp do złożonego podsystemu jednym interfejsem, ale nie rozsyła powiadomień, a Singleton jedynie gwarantuje istnienie jednej instancji klasy.

Dlaczego tak

Metoda generuj() w klasie bazowej ustala stały szkielet algorytmu — najpierw nagłówek, potem treść — i jest oznaczona final, aby podklasy nie mogły go zmienić. Podklasy dostarczają tylko wybrane kroki, tu abstrakcyjną metodę tresc(), więc wywołanie new RaportCsv().generuj() zwraca „R:a;b”. Kompozyt służy do budowy drzew obiektów traktowanych jednakowo jak pojedyncze elementy, a Fasada ukrywa złożony podsystem za prostym interfejsem.

Dlaczego tak

Zgodnie z ustawą o prawie autorskim autorskie prawa majątkowe do programu stworzonego przez pracownika w wyniku wykonywania obowiązków służbowych przysługują pracodawcy, chyba że umowa stanowi inaczej. Pracownik zachowuje autorskie prawa osobiste, w tym prawo do autorstwa, które są niezbywalne i nie wygasają. Sprzedaż licencji, pobieranie opłat i rozpowszechnianie to sposoby korzystania z praw majątkowych, więc należą do pracodawcy.

Dlaczego tak

Autorskie prawa majątkowe gasną z upływem 70 lat od śmierci twórcy, a okres ten liczy się w latach pełnych następujących po roku śmierci. Prawa trwają więc do końca roku 2010 + 70 = 2080, a potem przechodzą do domeny publicznej i licencja przestaje być potrzebna. Rok 2060 odpowiada dawnemu okresowi 50 lat, który w Polsce przedłużono do 70 lat. Prawa osobiste, np. do autorstwa, nie wygasają nigdy.

Dlaczego tak

Producent może dochodzić na drodze cywilnej zaniechania naruszeń, usunięcia ich skutków i naprawienia szkody, np. przez zapłatę dwukrotności wynagrodzenia, jakie należałoby się za licencję. Niezależnie od tego rozpowszechnianie cudzego utworu bez uprawnienia jest przestępstwem z ustawy o prawie autorskim, zagrożonym grzywną, karą ograniczenia albo pozbawienia wolności. Brak zysku nie wyłącza odpowiedzialności, a dozwolony użytek osobisty nie obejmuje programów komputerowych ani udostępniania ich nieznajomym.

Dlaczego tak

Znak towarowy chroni oznaczenie odróżniające towary lub usługi jednego przedsiębiorcy od innych — nazwę, logo lub ich połączenie — i daje prawo wyłącznego używania go po rejestracji w Urzędzie Patentowym RP lub w urzędzie Unii Europejskiej. Patent chroni rozwiązanie techniczne o charakterze wynalazku, a program komputerowy jako taki nie jest wynalazkiem. Wzór użytkowy dotyczy kształtu lub budowy przedmiotu, a licencja open source wręcz udostępnia kod innym.

Dlaczego tak

GPL jest licencją typu copyleft: program, który zawiera bibliotekę GPL i jest rozpowszechniany, staje się utworem zależnym i musi być udostępniony odbiorcom razem z kodem źródłowym na tych samych warunkach. Samo zachowanie informacji o autorze i treści licencji wystarcza przy licencjach permisywnych, takich jak MIT czy BSD. GPL nie zakazuje sprzedaży programu, wymaga jedynie, by kupujący otrzymał kod źródłowy i prawa wynikające z licencji.

Dlaczego tak

Kompilator C++ tłumaczy cały program przed uruchomieniem i tworzy plik wykonywalny z kodem maszynowym, więc u użytkownika kompilator nie jest potrzebny. Skrypt Python jest wykonywany przez interpreter, który musi być zainstalowany na komputerze użytkownika i tłumaczy program w czasie działania (najpierw do kodu bajtowego). Odpowiedź o konieczności kompilatora u użytkownika odwraca te role.

Dlaczego tak

Kompilator analizuje kod źródłowy i tłumaczy go na kod wynikowy, a przy tym zgłasza błędy składniowe i niezgodności typów — zanim program w ogóle się uruchomi. Debugger działa na uruchomionym programie: zatrzymuje go w punktach przerwania, pozwala wykonywać instrukcje krok po kroku i podglądać wartości zmiennych. Dlatego błędy logiczne, których kompilator nie widzi, wyszukuje się właśnie debuggerem.

Dlaczego tak

Poprawna suma elementów to 2 + 4 + 6 + 8 = 20, a debugger pokazuje 12, czyli brakuje dokładnie ostatniego elementu 8. Wynika to z range(len(t) − 1), który daje indeksy 0, 1, 2 zamiast 0–3; poprawnie ma być range(len(t)). Dzielenie przez len(t) − 1 dałoby 12 / 3 = 4.0, czyli też zły wynik — maskowałoby objaw, ale nie usuwało przyczyny.

Dlaczego tak

Preprocesor najpierw wykonuje dyrektywy #include i #define, wklejając pliki nagłówkowe i rozwijając makra. Następnie kompilator tłumaczy każdą jednostkę na plik obiektowy z kodem maszynowym, a konsolidator łączy pliki obiektowe i biblioteki w jeden plik wykonywalny, rozwiązując odwołania między nimi. Kompilacja przed preprocesorem jest niemożliwa, bo kompilator nie zna jeszcze deklaracji z dołączanych nagłówków.

Dlaczego tak

Biblioteka dynamiczna (w Windows .dll, w Linuksie .so) nie jest wbudowana w plik wykonywalny — system ładuje ją podczas uruchamiania programu, więc musi być obecna na komputerze docelowym. Kod biblioteki statycznej (.lib, .a) konsolidator kopiuje do pliku wykonywalnego, dlatego jej brak nie byłby zgłaszany przy uruchomieniu. Plik .dll zawiera skompilowany kod maszynowy, a nie źródłowy.

Dlaczego tak

Opcja -o podaje nazwę pliku wynikowego, więc g++ main.cpp -o program kompiluje i konsoliduje kod, tworząc plik wykonywalny program. Opcja -c zatrzymuje proces po kompilacji: powstaje tylko plik obiektowy, którego nie da się uruchomić. Zapis g++ -o main.cpp program jest groźny, bo plikiem wynikowym byłby main.cpp, a za plik wejściowy kompilator uznałby nieistniejący plik program.

Dlaczego tak

Zasada jednej odpowiedzialności mówi, że każda funkcja wykonuje jedno zadanie: tu wejście, obliczenia i wyjście trafiają do osobnych funkcji, które komunikują się przez parametry i wartości zwracane. Funkcję srednia(lista) można wtedy przetestować bez klawiatury i ekranu oraz użyć ponownie, np. dla ocen z pliku. Przekazywanie danych przez zmienne globalne ukrywa zależności między funkcjami i utrudnia testowanie.