BYT - Zagadnienia na egzamin PDF

BYT - Zagadnienia na egzamin Zagadnienia ogólne Definicja i role inżynierii oprogramowania Obejmuje praktyczną stronę informatyki w tym aspekty produkcji oprogramowania: analizę i określenie wymagań, projektowanie, implementację, wdrożenie, pielęgnację i...

BYT - Zagadnienia na egzamin Zagadnienia ogólne Definicja i role inżynierii oprogramowania Obejmuje praktyczną stronę informatyki w tym aspekty produkcji oprogramowania: analizę i określenie wymagań, projektowanie, implementację, wdrożenie, pielęgnację i ewolucję gotowego projektu. cykle życia oprogramowania; ewolucja oprogramowania podejścia i metodyki, np. obiektowość (UML) metody modelowania, analizy, projektowania, testowania inżynieria wymagań zagadnienia profesjonalizmu stosowanie metodyk, standardów, narzędzi; aspekty prawne, etyczne miary i oceny jakości oprogramowania proces wytwórczy kształt, zarządzanie, ocena, poprawa, ryzyko języki i techniki programowania Podaj główne charakterystyki projektu IT dziedzina wielkość, złożoność projektu innowacyjność / typowość projektu czas na wykonanie projektu znajomość i stopień stabilności wymagań wielkość zespołu i umiejętności poszczególnych osób dalszy rozwój systemu Czym jest kontekst projektu? BYT - Zagadnienia na egzamin 1  Kontekst projektu określa warunki, w jakich projekt jest realizowany, wpływa na decyzje dotyczące metodologii, strategii oraz zarządzania ryzykiem. Model i najważniejsze atrybuty projektu IT. Podaj właściwości projektu IT. Uproszczony model projektu IT: Klient - podmiot zamawiający system informatyczny Opis problemu - specyfikacja potrzeb klienta, określenie problemu do rozwiązania Specyfikacja problemu - dokumentowanie wymagań oraz zakresu projektu Specyfikacja rozwiązania - określenie sposobu realizacji projektu. Realizacja rozwiązania - faktyczna implementacja systemu Atrybuty projektu IT: Początek i koniec - określony czas realizacji Fazy / etapy - projekt podzielony na kroki (analiza, projektowanie, implementacja, testowanie) Produkty - wyniki poszczególnych etapów (np. dokumentacja, prototypy, finalny system) Zadania - podział na techniczne i menedżerskie Czas trwania i koszt - ograniczenia budżetowe i czasowe Zasoby - ludzie, infrastruktura, technologia Właściwości projektu IT: jednostkowość i złożoność ograniczenie środków wymaga pogodzenia pracy ludzkiej, zasobów, kapitału i czasu włącza w swój obręb różnych ludzi, funkcje i organizacje wymaga planowania, koordynacji i sterowania konsekwencje specyfiki produktu programowego tendencja do jak najwcześniejszego podjęcia implementacji rozległość dziedzin problemów wymagająca specjalistycznej wiedzy niestabilność wymagań BYT - Zagadnienia na egzamin 2  realizacja w układzie klient-dostawca trójkąt wymiarów projektu Co przedstawia i jaka jest rola tzw. wzbogaconego wizerunku? Wzbogacony wizerunek stanowi istotną pomoc dla analityka systemu, jako że zapewnia całościowe spojrzenie na obszar problemu, wymuszając większe jego zrozumienie. Konieczność “zgrania” punktów widzenia wielu udziałowców i wyrażenia ich na niewielkim obszarze wymusza ostrość spojrzenia na problem. Czym jest i co określa cykl życia projektu? Zbiór faz projektu, od jego rozpoczęcia do zakończenia, wyodrębnianych z uwagi na potrzeby sterowania nim przez organizację zaangażowaną w projekt. Cykl życia projektu określa: początek i koniec projektu akcje związane z rozpoczęciem (ustanowienie) i zakończeniem projektu wyodrębnianie fazy, ich powiązanie, przekazywane produkty zakres prac poszczególnych faz często związany z technologią BYT - Zagadnienia na egzamin 3  wykonawców faz sposób zarządzania projektem Specyfikacja wymagań Czym zajmuje się inżynieria wymagań? Inżynieria wymagań jest pozyskiwaniem, analizowaniem, dokumentowaniem, weryfikowaniem i walidacją funkcji, i ograniczeń projektowanego systemu (czyli wymagań) oraz zarządzaniem nimi. Techniki i narzędzia inżynierii wymagań (w tym diagram przypadków użycia i pojęcia: aktor, przypadek użycia, scenariusz, granica systemu, relacje między przypadkami użycia) Techniki inżynierii wymagań: pozyskiwanie wymagań modelowanie wymagań analiza i weryfikacja wymagań zarządzanie wymaganiami Narzędzia inżynierii wymagań: Diagramy przypadków użycia (Use Case Diagram) Aktor - użytkownik lub system, który wchodzi w interakcje z systemem Przypadek użycia - funkcja systemu, którą akto może wykonać Scenariusz - szczegółowy przebieg interakcji pomiędzy aktorem, a systemem Granica systemu - określa, co znajduje się wewnątrz systemu, a co poza nim Relacje: Include - przypadek użycia zawiera inny przypadek użycia Extend - przypadek może być rozszerzony o inny przypadek w określonych warunkach Generalizacja - przypadki użycia lub aktorzy mogą dziedziczyć cechy od innych BYT - Zagadnienia na egzamin 4  Diagramy sekwencji (Sequence Diagram) Diagram czynności (Activity Diagram) Modele związków jednostek (Entity-Relationship Model, ERD) Drzewa decyzjne Wymień cechy dobrego wymagania poprawne jednoznaczne kompletne spójne realistyczne (możliwe do zrealizowania) uporządkowane (wg ważności i stabilności) sprawdzalne (weryfikowalne, testowalne) modyfikowalne możliwe do śledzenia Wymień znane techniki pozyskiwania wymagań studia dziedzinowe - standardy regulacje, przepisy prawne, schematy, opisy procedur i stanowisk itp. analiza istniejącego procesu w firmie - gdzie jest problem? wywiady - pozyskiwanie informacji podczas bezpośredniej rozmowy z klientem obserwacje - obserwowanie istniejącego stanu rzeczy praca grupowa - np. “burza mózgów” ankiety, kwestionariusze prezentacje wstępnej reprezentacji zebranych wymagań (np. w postaci diagramu przypadków użycia) pozostałym udziałowcom eksperymenty prototypowanie BYT - Zagadnienia na egzamin 5  Podział wymagań stawianych oprogramowaniu Wymagania ogólne (biznesowe) Pozwalają umieścić system w kontekście biznesowym, technicznym i środowiskowym Wymagania funkcjonalne Stwierdzają, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. W niektórych wypadkach wymagania funkcjonalne określają czego system nie powinien robić Wymagania niefunkcjonalne Określają ograniczenia usług i funkcji systemu (czasowe, dotyczące procesu tworzenia, standardów itd.) Wymagania dziedzinowe Odzwierciedlają charakterystykę dziedziny zastosowania systemu. Mogą być zarówno funkcjonalne jak i niefunkcjonalne. Klasyfikacja wymagań niefunkcjonalnych Wymagania produktowe Określają zachowanie produktu. Przykładami są wymagania efektywnościowe dotyczące szybkości działania systemu i jego zapotrzebowania na pamięć, wymagania niezawodności Wymagania organizacyjne Wynikają ze strategii i procedur w firmie klienta i w firmie wytwórcy Wymagania zewnętrzne Ta szeroka kategoria mieści wszystkie wymagania wynikające z czynników zewnętrznych. Obejmują m.in. wymagania współpracy, które definiują interakcje systemu z systemami innych firm i wymagania prawne. Czym są stories? Podaj przykłady Opisują co użytkownik chce zrobić i dlaczego, bez technicznych szczegółów. “Jako administrator Systemu, chcę stworzyć pierwsze konto użytkownika Suezmax w nowo zainstalowanym systemie, aby móc zalogować się do Suezmax.” “Jako użytkownik Suezmax, chcę zalogować się na swoje konto, aby pracować z systemem.” BYT - Zagadnienia na egzamin 6  Identyfikacja i analiza wymagań w podejściu agile Wymagania są identyfikowane w sposób przyrostowy i iteracyjny, a zamiast szczegółowej specyfikacji tworzy się historyjki użytkownika. Zasadniczy wynik: rejestr produktowy (rejestr zaległości produktu) opis zasad (reguł) biznesowych zbiór scenariuszy użytkowych (historyjek) słownik pojęć wsparcie notacjami modelującymi (przypadki użycia) Projektowanie oprogramowania Czym jest architektura aplikacji? Architektura aplikacji to struktura systemu informatycznego, określająca sposób jego organizacji, podziału na komponenty oraz ich wzajemne powiązania. Architektura uwzględnia: komponenty systemu (moduły, usługi, bazy danych) integracje (API, mikrousługi, komunikacja między modułami) bezpieczeństwo (np. autoryzacje, szyfrowanie danych) wydajność i strukturowalność (jak system reaguje na wzrost liczby użytkowników) sieć i przepływy danych (jak informacje są przesyłane wewnątrz systemu) interfejs użytkownika (UX/UI) wykorzystywane technologie (języki programowania, frameworki) Podaj definicje podsystemu i cele podziału systemu na podsystemy Podsystem to wydzielona część większego systemu, posiadająca własną funkcjonalność i interfejs, ale działająca w ramach tego samego systemu. Każdy podsystem może mieć własne moduły i komponenty, ale jest częścią większej całości. BYT - Zagadnienia na egzamin 7  Podsystemy komunikują się ze sobą, często poprzez interfejsy API lub inne mechanizmy integracji. Cele podziału systemu na podsystemy: Lepsza organizacja kodu Ułatwienie skalowania i rozwoju systemu Zarządzanie zespołem Bezpieczeństwo i niezawodność Wykorzystanie różnych technologii Poprawa wydajność Ponownego użycia kodu Podaj przykładowe komponenty systemu np. aplikacji webowej Frontend Backend Baza danych Serwer Monitorowanie Obsługa plików Czym są wzorce projektowe? Podaj znany Ci wzorzec i scharakteryzuj go. Wzorce projektowe (Design Patterns) to sprawdzone i powtarzalne sposoby rozwiązywania typowych problemów programistycznych w projektowaniu oprogramowania. Można je dostosować do różnych sytuacji w kodzie. Builder (wzorzec kreacyjny), umożliwia stopniowe konstruowanie obiektów. Separuje proces tworzenia obiektu od jego reprezentacji, dzięki czemu można tworzyć jego różne warianty. Struktura: 1. Klasa Obiektu, definuje obiekt 2. Interfejs Buildera, deklaruje metody budowania obiektu BYT - Zagadnienia na egzamin 8  3. Konkretna implementacja, tworzy różne wersje obiektu Mikrousługi, konteneryzacja, chmura obliczeniowa Mikrousługi to architektura oprogramowania, w której system składa się z małych, niezależnych usług, które komunikują się przez API. Każda mikrousługa ma własną logikę biznesową, bazę danych i może działać niezależnie od innych. Umożliwia łatwe skalowanie i wdrażanie zmian bez wpływu na cały system. Konteneryzacja (Docker, Kubernetes) to sposób pakowania aplikacji z jej zależnościami w jeden przenośny pakiet (kontener). Umożliwia łatwe wdrażanie i uruchamianie aplikacji na różnych środowiskach (chmura, serwer, lokalny komputer) Chmura obliczeniowa (Cloud Computing) to model dostarczania zasobów IT przez internet, zamiast na lokalnych serwerach. Proces wytwarzania oprogramowania i strategie Fazy (etapy, czynności) w procesie budowy oprogramowania 1. Analiza i zbieranie wymagań a. identyfikacja wymagań b. analiza biznesowa i techniczna c. tworzenie modelu przypadków użycia (Use Case Diagram) d. określenie ról użytkowników w systemie e. przygotowanie specyfikacji wymagań 2. Projektowanie systemu a. wybór architektury aplikacji b. podział na podsystemy i komponenty c. modelowanie klas i struktur danych d. zaprojektowanie UX/UI e. określenie wymagań dotyczących bezpieczeństwa BYT - Zagadnienia na egzamin 9  3. Implementacja a. wykorzystanie wzorców projektowych i. programowanie zgodne z architekturą systemu b. integracja backendu i frontendu c. implementacja API i bazy danych d. dokumentacja kodu 4. Testowanie a. testy jednostkowe b. testy integracyjne c. testy wydajnościowe d. testy bezpieczeństwa e. testy akceptacyjne 5. Wdrożenie i utrzymanie a. wdrożenie na serwery lub chmurę b. monitorowanie systemu i logowanie błędów c. tworzenie kopii zapasowej danych d. aktualizacje i poprawki bezpieczeństwa e. rozwijanie nowych funkcji Modele tradycyjne: charakterystyka, podział, role osobowe, zalety, wady, zastosowanie Model kaskadowy (Waterfall) Pod pojęciem kaskadowy cykl życia systemu rozumie się całość działań, wraz z ich produktami, wzajemne relacjami oraz zależnościami w czasie, prowadzonych od ujawnienia potrzeby budowy systemu, poprzez analizę stawianych wymagań, projektowanie i implementację oprogramowania, testowanie, jego wdrożenie i pielęgnację, do zakończenia wykorzystania oprogramowania. Zalety: 1. klarowna struktura, łatwa do zarządzania BYT - Zagadnienia na egzamin 10  2. obejmuje cały cykl życia oprogramowania 3. wprowadza systematykę 4. sprawdzony, zweryfikowany praktycznie 5. uwypukla analizę i projektowanie, ze szczególnym uwzględnieniem aspektów technicznych rozwiązania Wady: 1. rozwiązanie widzimy dopiero na końcu projektu 2. silnie zależy od stabilności wymagań, która jest bardzo trudna do uzyskania 3. oderwanie od użytkownika i klienta, który w projekcie jest tylko na początku i końcu 4. wysokie koszty naprawy błędów 5. poprawa bądź konieczność dopasowania produktu do rzeczywistych potrzeb użytkownika prowadzi do wzrostu kosztów 6. niska produktywność i motywacja zespołu Zastosowanie: 1. stabilne i dostępne wymagania, dobrze określone zadania 2. niezbyt duży projekt 3. niewielkie ryzyko 4. niezbyt ostre wymagania jakościowe 5. znana i stabilna technologia Role: Analityk biznesowy - zbiera i analizuje wymagania klienta Architekt systemu - projektuje ogólną strukturę systemu Programista - implementuje kod źródłowy systemu Tester - weryfikuje poprawność działania systemu Menedżer projektu - zarządza harmonogramem i budżetem Administrator systemu - odpowiada za wdrożenie i utrzymanie systemu Model V (V-Model, Weryfikacja, Walidacja) Zalety: BYT - Zagadnienia na egzamin 11  1. przenosi wszystkie zalety cyklu klasycznego 2. wysoka jakość wytwarzanego produktu 3. istotne obniżenie kosztów utrzymania systemu 4. obniżenie ryzyka popełnienia grubego błędu Wady: 1. znaczne narzuty pracy, czasu i kosztu realizacji systemu 2. silne rozbudowanie dokumentacji 3. częstym skutkiem jest zniechęcenie zespołów realizacyjnych i pojawienie się konfliktów związanych z dokonywaniem ocen przez osoby niezwiązane z danym elementem prac Zastosowanie: 1. zależny nam na wysokiej jakości produktu 2. możemy sobie pozwolić na zwiększone nakłady Role osobowe: Analityk biznesowy - zbiera i analizuje wymagania klienta Architekt systemu - projektuje ogólną strukturę systemu Programista - implementuje kod źródłowy systemu Tester - weryfikuje poprawność działania systemu Menedżer projektu - zarządza harmonogramem i budżetem Administrator systemu - odpowiada za wdrożenie i utrzymanie systemu Model spiralny: charakterystyka, role osobowe, zalety, wady, zastosowanie Model spiralny (Spiral Model) to połączenie idei modelu przyrostowego oraz kaskadowego. Zalety: akceptuje zmiany wymagań podkreśla bardzo wykorzystywanie prototypów użytkownicy/klienci są zaangażowani w proces przydatne w dużych przedsięwzięciach BYT - Zagadnienia na egzamin 12  przydatne jak uczymy się technologii Wady: proces jest skomplikowany niespójna architektura i projekt rozwiązania nieokreślony koniec projektu trudniejsze zarządzanie drogi w zastosowaniu Zastosowanie: duże przedsięwzięcia projekty wysokiego ryzyka nieznane wymagania spodziewane są zmiany wymagań istnieje dużo gotowych komponentów Role osobowe: menedżer projektu - zarządza harmonogramem, budżetem i organizacją kolejnych itercji spirali analityk biznesowy - zbiera wymagania, analizuje potrzeby klienta i aktualizacje dokumentacje w każdej iteracji architekt systemu - projektu ogólną strukturę systemu oraz nadzoruje podział na komponenty i podsystemy inżynier ds. ryzyka - analizuje potencjalne zagrożenia, identyfikuje problemy i definiuje sposoby ich eliminacji programista - implementuje kod źródłowy zgodnie z wymaganiami i architekturą projektu tester - przeprowadza testy jednostkowe, integracyjne i systemowe w każdej iteracji specjalista ds. jakości - odpowiada za kontrole jakości kodu i zgodność z wymaganiami Główne zasady manifestu Agile 1. Najwyższy priorytet ma dla na zadowolenie klienta dzięku wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania. BYT - Zagadnienia na egzamin 13  2. Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności. 3. Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej tym lepiej. 4. Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu. 5. Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonują powierzone zadanie. 6. Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu wewnątrz niego jest rozmowa twarzą w twarz. 7. Działające oprogramowanie jest podstawową miarą postępu. 8. Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy. 9. Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność 10. Prostota - sztuka minimalizowania ilości koniecznej pracy - jest kluczowa 11. Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samo organizujących się zespołów. 12. W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków. Modele zwinne: geneza, charakterystyka, podział, role osobowe, zalety, wady, zastosowanie Extreme programming maksymalne uproszczenie projektu ścisły kontakt z odbiorcą oprogramowania artefakty: kod + przypadki testowe programowanie przez dwóch programistów (parami) ciągłe testowanie (jednostkowe i funkcjonalne), integracja aplikacji Feature Driven Development (FDD) budowa modelu ogólnego BYT - Zagadnienia na egzamin 14  lista cech (funkcjonalności) do wytworzenia zaplanowanie wytworzenia funkcjonalności zaprojektowanie funkcjonalności implementacja funkcjonalności Behaviour-Driven Development (BDD) określa, że testy dowolnej jednostki oprogramowania powinny być opisane pod kątem pożądanego zachowania od czego zacząć w procesie co testować, a czego nie testować ile można przetestować za jednym razem jak zdefiniować testy jak zrozumieć przyczynę ewentualnego niepowodzenia testu Test Driven Development (TDD) zdefiniowanie i budowa testu uruchomienie wszystkich testów i sprawdzenie, czy nowy test się nie powiódł implementacja kodu, dla którego test powinien się powieść uruchomienie testów refaktoring kodu powtórzenie kroków dla kolejnego testu Agile Unified Process Obszary zarządzania model implementacja testowanie wdrożenie zarządzanie konfiguracją continous… - integration, delivery, deployment zarządzanie projektem BYT - Zagadnienia na egzamin 15  środowisko wytwarzania Zasady pełne zaufanie do zespołu prostota rozwiązań zwinność skupienie na czynnościach dodających wartości niezależność od narzędzi elastyczność procesu SCRUM Kanban wizualizuj ogranicz pracę w toku zarządzaj przepływem pracy. Mierz Lead Time objaśnij zasady procesu stosuj pętle informacji zwrotnych udoskonalaj Scaled SCRUM - SAFe, Nexus SCRUM: definicje: sprint, rejestr produktów, rejestr sprintu, daily, weekly, wykresy wypalania itp. Sprint - iteracja o stałej długości (zwykle 2-4 tygodnie), w której zespół realizuje zadania Rejestr Produktów - lista wszystkich zadań, które zostały wybrane do realizacji w danym sprincie Daily Stand-up - krótkie, codzienne spotkanie zespołu (max. 15 minut), na którym każdy członek zespołu odpowiada na trzy pytania: Co zrobiłem wczoraj? Co planuję zrobić dzisiaj? Czy napotkałem jakieś przeszkody BYT - Zagadnienia na egzamin 16  Weekly Meeting - cotygodniowe spotkanie zespołu podsumowujące postęp prac w sprincie, pokazująca, ile pracy jeszcze pozostało Wykres wypalania sprintu - wizualizacja postępu prac w sprincie, pokazująca, ile pracy jeszcze pozostało Wykres wypalania produktu - pokazuje ogólny postęp prac nad całością projektu. Zarządzanie projektem informatycznym Podaj definicję projektu Projekt to szereg zaplanowanych działań prowadzących do budowy (lub rozbudowy) systemu komputerowego. W kontekście inżynierii oprogramowania określany jest również jako Software Development Process. Kim jest interesariusz projektu? Interesariusz to osoba, grupa lub organizacja, która ma wpływ na projekt lub jest pod jego wpływem. Nie jest bezpośrednio zaangażowany w projekt, ale jego wyniki mają na nie istotny wpływ. Ma interes w ukończeniu projektu. Ich opinie i potrzeby powinny być uwzględnione przez kierownika projektu oraz sponsora. Podaj definicję ryzyka projektowego i podaj przykład ryzyka w projekcie informatycznym Ryzyko projektowe to możliwość wystąpienia niechcianej sytuacji, która obniża poziom sukcesu projektu lub prowadzi do jego całkowitego niepowodzenia z punktu widzenia interesariuszy. Przykład: Niestabilność wymagań Fakt: Klient często zmienia wymagania. Ryzyko: Nowe wymagania mogą pojawić się w późnej fazie projektu. Efekt: Wzrost kosztów i opóźnienia w harmonogramie. Podaj 3 (z 10) obszary zarządzania projektami 1. Model BYT - Zagadnienia na egzamin 17  2. Implementacja 3. Testowanie 4. Wdrożenie 5. Zarządzanie konfiguracją 6. Zarządzanie projektem 7. Środowisko wytwarzania Kanban: co przedstawia tablica Kanbana? To wizualne narzędzie do zarządzania przepływem pracy. Jest używane w metodologii Kanban, aby zobrazować postęp zadań i ograniczyć pracę w toku. (To do, In Progress, Review, Done) Kodowanie i bezpieczeństwo kodu Clean Code - czym charakteryzuje się dobry kod źródłowy 1. Łatwy do zrozumienia 2. Powinien czytać się jak dobrze napisany tekst 3. Nie powinien ukrywać intencji programisty 4. Czytelne i opisowe nazwy 5. Komentarze powinny być zbędne 6. Nie należy stosować komentarzy do dokumentowania rzeczy oczywistych 7. Nie używać komentarzy do przechowywania logów zmian 8. Każda klasa i funkcja powinna mieć jedno, jasno określone zadanie 9. Nie tworzyć “superklas” z wieloma odpowiedzialnościami 10. Należy stosować stałe i wyraźne nazwy 11. Jeszcze lepsze rozwiązanie to stosowanie obiektowego podejścia 12. Funkcje powinny być krótkie (max. 20 linii kodu) 13. Każda funkcja powinna robić tylko jedną rzecz 14. Jeśli funkcja jest za długa, należy ją podzielić na mniejsze funkcje pomocnicze BYT - Zagadnienia na egzamin 18  15. Stały styl kodowania w całym zespole 16. Zachowanie odpowiednich wcięć i podziałów 17. Preferowanie wielu małych plików zamiast jednego dużego plików (200 - 500 linii na plik) 18. Zewnętrzne biblioteki powinny być opakowane w klasy abstrakcyjne 19. Należy unikać niejednoznacznych nazw 20. Minimalizacja liczby argumentów w funkcjach Zasady tworzenia czystego kodu 1. Czytelność kodu 2. Konwencje nazewnictwa 3. Minimalizacja komentarzy 4. Zasada pojedynczej odpowiedzialności 5. Unikanie “magicznych liczb” 6. Krótka długość funkcji i modułowość 7. Spójne formatowanie kodu 8. Unikanie bezpośredniego używania bibliotek zewnętrznych 9. Kontekst nazw zmiennych i klas 10. Minimalizacja liczby argumentów w funkcjach Konwencje nazywania zmiennych 1. Nazwy powinny być opisowe i zrozumiałe 2. Unikaj jednoliterowych nazw zmiennych 3. Unikaj “magicznych liczb” 4. Kontekst w nazwach zmiennych 5. Struktura nazw (camelCase, PascalCase, Snake_Case) Architektura systemów kontroli wersji BYT - Zagadnienia na egzamin 19  1. Systemy lokalne - wersjonowanie plików odbywa się na pojedynczej maszynie użytkownika 2. Systemy centralne (scentralizowane) - CVS, SVN - posiadają centralne repozytorium, z którego użytkownicy pobierają pliki i zapisują zmiany 3. Systemy rozproszone (DVCS) - Git, Mercurial - każdy użytkownik ma lokalną kopię repozytorium z pełną historią zmian Ogólna znajomość OWASP TOP10 1. Uszkodzona kontrola dostępu (Broken Access Control) 2. Awarie kryptograficzne 3. Wstrzykiwanie 4. Niepewny projekt 5. Błędna konfiguracja zabezpieczeń 6. Podatne i przestarzałe komponenty 7. Błędy identyfikacji i uwierzytelniania 8. Awarie oprogramowania i integralności danych 9. Rejestrowanie zabezpieczeń i monitorowanie awarii 10. Fałszowanie żądań po stronie serwera Testowanie oprogramowania Testowanie oprogramowania a jakość oprogramowania Jest kluczowym elementem zapewnienia jakości (QA), ale samo testowanie nie jest równoznaczne z wysoką jakością. Pomaga wykryć defekty, ale jakość oprogramowania zależy także od procesów, planowania i architektury systemu. Weryfikacja, walidacja i testowanie (VVT) są niezbędne, aby zapewnić poprawne działanie aplikacji i spełnienie wymagań użytkowników. Scenariusze Testowe, Przypadki Testowe, Skrypty Testowe Scenariusz testowy to systematyczna obserwacja oczekiwanego działania programu. Najczęściej jest to sekwencja przypadków testowych, które mają sprawdzić określoną BYT - Zagadnienia na egzamin 20  funkcjonalność. → zbiór przypadków testowych Przypadek testowy to obserwacja działania programu, związana z interpretacją interesującego nas zdarzenia, danymi i funkcjami. Każdy przypadek testowy składa się z warunków testu, danych wejściowych, czynności, oczekiwanych wyników i kryteriów akceptacji. → opisuje konkretne wejścia, kroki i oczekiwane wyniki Skrypt testowy to zbiór instrukcji, często programistycznych, które automatyzują wykonanie testu. Jest stosowany w testach automatycznych i może być napisany w językach skryptowych, takich jak Python, JavaScript czy Java. → automatyzuje wykonanie testu w kodzie Poziomy testowania - jednostkowe, integracyjne, systemowe (end to end) Testy jednostkowe sprawdzają pojedyncze fragmenty oprogramowania (klasa, metoda czy funkcja). Są wykonywane w celu upewnienia się, że każdy fragment kodu działa poprawnie w izolacji. bardzo szybkie nie wymagają pełnego uruchomienia aplikacji łatwe do automatyzacji testują wszystkie ścieżki w kodzie i wartości brzegowe nie wykrywają błędów integracyjnych Testy integracyjne sprawdzają, czy różne moduły systemu współpracują poprawnie. sprawdzają komunikację między modułami mogą wykryć błędy, których nie wykryły testy jednostkowe bardziej czasochłonne niż testy jednostkowe mogą wymagać symulacji komponentów Testy systemowe (End-to-End) sprawdzają całą aplikację jako jedną całość, działającą w docelowym środowisku. testują aplikację w pełnym środowisku sprawdzają wydajność, bezpieczeństwo i zachowanie systemu BYT - Zagadnienia na egzamin 21  mogą być trudne do automatyzacji i kosztowne długotrwałe Testy akceptacyjne to ostatnia faza testowania, której celem jest potwierdzenie, że system spełnia wymagania użytkownika i klienta. Wyróżniamy testy UAT, które wykrywają wszelkie niezgodności ze specyfikacją biznesową, oraz testy OAT sprawdzające na przykład zachowanie systemu podczas awarii. Rodzaje testów - testy funkcjonalne i testy niefunkcjonalne Testy funkcjonalne sprawdzają czy oprogramowanie realizuje wymagane funkcje zgodnie ze specyfikacją. Testy “czarnej skrzynki” - tester nie zna kodu źródłowego, sprawdza jedynie zachowanie systemu Testy skupiają się na przypadkach użycia Nie wymagają znajomości wewnętrznej struktury systemu Zwykle bazują na dokumentacji wymagań Testy niefunkcjonalne badają jak działa system, a nie co robi. Obejmują wydajność, bezpieczeństwo i użyteczność. nie dotyczą samej funkcjonalności, ale sposób działania systemu badają cechy jakościowe oprogramowania (np. czas odpowiedzi, zużycie zasobów) zwykle wymagają specjalistycznych narzędzi do testowania wydajności i bezpieczeństwa. BYT - Zagadnienia na egzamin 22