PSI
PSI Architectural Design Quiz
Test your knowledge on architectural design and quality assessment methodologies with our comprehensive PSI quiz. This interactive quiz covers fundamental concepts in software engineering, focusing on principles such as coupling, cohesion, and design quality.
Topics include:
- Architectural styles and decisions
- Quality assessment models
- Software development methodologies
- Usability and fun
ctional requirements
Attribute Driven Design to metoda dekompozycji oparta na wymaganiach użytkownika skatalogowanych w postaci scenariuszy powiązanych z atrybutami jakościowymi.
Prawda
Fałsz
Styl architektoniczny określa:
Rozwiązania problemów związanych z konkretnymi technologiami
Żadna z odpowiedzi nie jest poprawna
Kolekcje modułów implementujących dane rozwiązane
Sposób projektowania elementów systemu I ich powiązań
Kohezja funkcjonalna określa sytuację, w której wszystkie elementy komponentu realizują wspólną funkcję
Prawda
Fałsz
Coupling struktury danych oznacza sytuację, w której komponenty komunikują się przez zewnętrzne medium np. Plik z danymi
Prawda
Fałsz
Jakość produktu oceniamy
Zgodnie z metodyką SPICE
Zgodnie z modelem ISO 9126
Zgodnie z modelem ISO 9001
Zgodnie z metodyką CMM
Ocena systemu lub komponentu podczas lub na końcu procesu jego rozwoju na zgodności z wyspecyfikowanymi wymaganiami to (wybierz najpełniejszą odpowiedź)
Atestowanie
Weryfikacja
Testowanie
Formalny odbiór przez klienta
Jaki styl architektury najlepiej zaproponować w sytuacji gdy: „transformacje polegają na inkrementalnym przetwarzaniu danych wejściowych”:
Workflow
System z podsystemami
Abstrakcyjny typ danych
Repozytorium
Brak możliwości zmian w działaniu etapów zakończonych to cecha modelu cyklu życia systemu informatycznego:
Typu Agile
Przyrostowego
Iteracyjnego
Liniowego
Decyzja architektoniczna może dotyczyć
Zastosowania określonego wzorca
Wszystkie odpowiedzi są prawidłowe
Wykorzystania konkretnego stylu architektonicznego
Wykorzystania określonej technologii do implementacji komponentu
Komponent zarządzający sekwencją zdarzeń nazywamy komponentem:
Kontrolerem
Zarządzającym
Obliczeniowym
Pamięciowym
Jakie rozwiązanie najlepiej zaproponować dla następującego problemu „słabopowiązana kolekcja komponentów, z których każdy wykonuje określone operacje I umożliwia wykonania innych. Brak powiązania generujących I odbierających sygnały (korzystne np. Przy zamianie dostawców)”
Każdy komponent zarządza swoimi danymi. Jeśli inny komponent chce ich użyć musi odwołać się do określonej metody, a nie do określonych danych.
Stworzenie hierarchii komponentów (zależy od siebie), oraz hierarchii danych (danych lokalnych, globalnych)
System zapewniający przepływ danych pomiędzy komponentami
Model oparty o zdarzenia
Diagram WBS pozwala na analizę powiązań zadań oraz ich czasów trwania, a także ustalenie ścieżki krytycznej projektu.
Prawda
Fałsz
Mock-up jest to:
Model demonstrujący klientowi funkcjonalności systemu, czasem wykonany w MS Power Point
Artefakt wykorzystywany w fazie planowaniu systemu
Wynik fazy projektowania w cyklu życia systemu
Prototyp systemu z zaimportowaną I przetestowaną częścią funkcjonalności
Kohezja temporalna określna sytuację, w której elementy w komponencie powinny być wywoływane w określonym porządku
Prawda
Fałsz
W metodach ilościowych E uzależnianie od liczby linii kodu oznacza:
Czas trwania projektu
Pracochłonność
Cenę za linię kodu
Wielkość budżetu projektu
Użyteczność systemu jest wymaganiem pozafunkcyjnym określającym
Wszystkie odpowiedzi są poprawne
ŝatwość użycia
Dostępność materiałów szkoleniowych
Dostępność dokumentacji dla systemu
Podejście extreme programming zakłada:
Wszystkie powyższe są prawidłowe
Ciągły udział klienta w tworzeniu oprogramowania
Ciągłe monitorowanie jakości tworzonego oprogramowania
Podejście iteracyjne do tworzenia oprogramowania
Model Driven Architecture (MDA) jest:
Podejściem do tworzenia architektury systemu polegającym na tworzeniu kodu z modelu I wprowadzaniu poprawek do kodu po wcześniejszej zmianie modelu
Podejściem do tworzenia architektury systemu polegającym na tworzeniu kodu z modelu, a następnie wprowadzaniu poprawek do kodu I na tej podstawie poprawie modelu
Rodzajem architektury systemu informatycznego konkurencyjnym do Model View Controller
Metodyką tworzenia oprogramowania stworzoną przez IBM
Najlepszą (najefektywniejszą I powodującą najmniej problemów w implementacji I zarządzaniem rozwojem oprogramowania) strukturą programu jest:
Drzewo
Graf skierowany
Acykliczny graf skierowany
Graf warstwowy
Elementem diagramu przepływu danych NIE jest
Przepływ danych
Byt zewnętrzny
Proces przekształcenia danych
Element struktury systemu (komponent)
ŝatwość nauczenia, szybkość działania, odporność na błędy użytkownika czy zdolność wycofania wskazują na następujące wymagania jakościowe:
Czytelność
Prostota
Użyteczność
Efektywność
Ocena architektury polega na określeniu:
Niebezpieczeństw dla realizacji systemu zgodnie z wymaganiami
Możliwości realizacji systemu z wykorzystaniem dostępnych zasobów
Zgodności systemu z wymaganiami jakościowymi
Wszystkie odpowiedzi są prawidłowe
W metodzie Halsteada przykładem operatora NIE jest:
J
Sort()
Public
Int
Założenia dla decyzji architektonicznej związane są z:
Środowiskiem, w którym podejmowana jest decyzja
Złożenia dotyczą status decyzji
Kwestiami architektonicznymi, których dotyczy decyzja
Ewentualnych powiązań decyzji z innymi decyzjami
W modelu tworzenia oprogramowania 40-20-40, 20 oznacza, że
20 procent kosztów związanych jest z testowaniem
20 procent czasu należy poświęcić na testowanie
20 procent kosztów związanych jest z programowaniem
20 procent czasu tworzony jest kod dla rozwiązania
Typowym „grzechem” analityka w procesie specyfikacji wymagań nie jest:
Doprowadzenie do sprzeczności między wymaganiami
Brak zaadresowania wymagania
Opis rozwiązania problemu użytkownika
Tworzenie powiązań między funkcjonalnościami (tworzenie hierarchii wymagań)
Stopień II Powtarzalności w modelu CMM określa sytuację, w której
Optymalizuje się proces produkcji oprogramowania
Tworzy się procedury zarządzania relacjami z dostawcami I klientami
Szczegółowo definiuje się proces produkcji oprogramowania
Wszystkie odpowiedzi są prawidłowe
Styl architektoniczny określony jest przez następujące elementy (wybierz najpełniejszą odpowiedź)
Ograniczenia dla systemu wynikające ze środowiska dla tworzonego systemu oraz propozycji rozwiązania ograniczeń
Sytuację, której dotyczy proponowane rozwiązanie wraz z proponowanym rozwiązaniem
Problem, ograniczenia dla środowiska I rozwiązanie
Zbiór decyzji architektonicznych dotyczących komponentów
Cechami oprogramowania uzyskanego w procesie Software Enginnering, zgodnie z definicją jest:
Wiarygodność
Bezpieczeństwo
Niezaprzeczalność
Użyteczność
Efektem fazy elaboration (uszczegółowienie) w Rational Unified Process jest:
Kod produktu
Business case
Architektura systemu
Kontekst projektu
W sytuacji projektowej, gdy nieznane są zarówno produkt, proces tworzenia, jak I zasoby, które możemy wykorzystać najlepszą strategią wykonania będzie
Podejście agile
Prototypowanie
Podejście inkrementalne
Wszystkie odpowiedzi są prawidłowe
Najsilniejsze powiązanie między komponentami określa sytuację, w której jeden komponent swoją działalnością wymusza zmiany na innym komponencie
Prawda
Fałsz
Poprawnie zaprojektowana architektura pozwala spełnić następujące wymagania pozafunkcjonalne
Wszystkie odpowiedzi są prawidłowe
Wydajność
Użyteczność
Bezpieczeństwo
Cechą kaskadowego podejścia do tworzenia oprogramowania nie jest:
Ciągły kontakt z klientem
ŝatwość rozliczeń z klientem
Techniczna łatwość harmonogramowania I budżetowania
Formalny odbiór poszczególnych etapów prac
Technika Gilba w procesie badania satysfakcji użytkownika polega na podziale każdego wymagania jakościowego na podkategorie którym przpisywane są miary
Prawda
Fałsz
W przypadku oprogramowania typu COTS mamy do czyniania z :
Wszystkie odpowiedzi są prawidłowe
Możliwością dostosowania ( w pewnym zakresie) systemu do potrzeb użytkownika
Tworzeniem rankingu komponentów zgodnie z piorytetami użytkownika
Typowym, jak w przypadku rozwiązań tworzonych na zamówienie, procesem specyfikacji wymagań
W modelu McCalla
Jednemu czynnikowi może odpowiadać wiele kryteriów ( przyporządkowanych do nie więcej niż jednego czynnika)
Czynnikom jakości przydzielono odpowiednie kryteria je opisujące , a następnie podzielono na pięć kategorii
Przyporządkowanie kryteriów do czynnikóa. Jest na zasadzie m:n
Czynnik jakości onzacza wewnętrzne cechy systemu , które można mierzyć w sposób obiektywny lub subiektywny
Specyfikacja wymagań użytkownika:
Stanowi punkt startowy dla definicji testów systemu
Jest kontraktem dla klienta systemu
Stanowi punkt startowy dla projektu systemu
Wszystkie odpowiedzi są prawidłowe
Jaki styl architektoniczny najlepiej zaproponować dla następującego problemu : “System może być opisany jako szereg wywołanych po sobie procedur”
Pośrednie wywołanie
Abstrakcyjny typ danych
System z podsystemami
Repozytorium
Miara CBO dla klasy posiadającej jedną nadklasę I dwie klasy powiązane z nią relacją asocjacji wynosi :
Dla takich danych nie można wyznaczyć miary CBO
2
1
3
Możliwe jest jednoczesne zapewnienie wysokiej spójności wewnętrznej komponentów oraz niskiego stopnia powiązań między komponentami (generalnie balansowanie I interfejsy)
Prawda
Fałsz
W przypadku gdy liczba stanów wynosi 10, istnieje jeden wierzchołek początkowy I końcowy , zaś liczba przejść wynosi 18 , miara CV przyjmie wartość :
6
10
12
8
Model CMM dotyczy oceny dojrzałości procesu tworzenia oprogramowania
Prawda
Fałsz
Wzorce projektowe dostarczają
Rozwiązań nieznanych problemów
Komponentów programowych zbudowanych zgodnie z najlepszymi praktykami
Kodyfikacji doświadczenia z dziedziny
Jednoznacznych I precyzyjnych rozwiązań znanych problemów
Ocena architektury jest fazą testowania systemu zanim zostanie stworzony dla niego kod
Prawda
Fałsz
Elementami drzewa użyteczności w metodzie ATAM są:
Korzeniem jest dowolne wymaganie funkcjonalne , dla którego określane są wymagania jakościowe wraz z wartościami
Korzeniem jest użyteczność , elementami scenariusze I wymagania jakościowe a liśćmi konkretne wartości
Korzeniem jest użyteczność , elementami wymagania jakościowe z określonego katalogu wymagań dla metody ATAM , zaś liścmi konkretne ich wartości
Korzeniem jest użyteczność , elementami dowolne wymagania jakościowe a liścmi konkretne ich wartości
Cechą reverse engineeringu jest :
Identyfikacja komponentów systemu oraz ich wzajemnych powiązań
Wprowadzenie zmian w systemie
Stworzenie kodu systemu na podstawie projektu
Inspekcja infrastruktury dla kodu
Metoda Halsteada służy do oceny kompleksowości oprogramowania . Jej celem jest ustalenie wielkości zespołu projektowego jak powinien realizować zadanie
Prawda
Fałsz
Założeniem leżącym u podstaw Jackson Structured Programming jest, że dobry program odzwierciedla strukturę wejść I wyjść (czyli na podstawie dobranego modelu danych można stworzyć odpowiedni program)
Prawda
Fałsz
W modelu Kano wymagania konieczne (must have) oznaczają wymgania które :
Muszą być uwzględnione przy tworzeniu a ich uwzględnienie powoduje proporcjonalny wzrost satysfakcji
Żadna z odpowiedzi nie jest prawidłowa
Gdy spełnione są neutralne dla użytkownika
Muszą być uwzględnione I ich spełnienie powoduje wykładniczy wzrost satysfakcji użytkownika
Następujące cechy, działające modele systemu , duża interakcja z użytkownikiem ,redukcja czasu oczekiwania na rezultaty czy nacisk na interfejs użytkownika to klasyczne cechy
Prototypowania
Podejście spiralne
Rapid Application Development
EXtreme Programming
Komponent pobierający I zawracający parametry określonego typu nazywamy komponentem
Pamięciowym
Kontrolerem
Obliczeniowym
Zarządzającym
Stopień III Zdefiniowany w modelu CMM określa sytuację w której
Kładzie się nacisk na poprawę procesów poprzez ilościowe zarządzanie projektem
Kontroluje się plany I zobowiązania
Definiuje się procedury w zakresie zarządzania ryzykiem
Definiuje się procedury w zakresie innowacji dla produktu I procesu
Model CMM może być wykorzystany przez dowolną firmę tworzącą oprogramowanie
Prawda
Fałsz
Architektura systemu określa:
Wszystkie odpowiedzi są poprawne
Stanowi medium komunikacyjne wyłącznie między projektantami a testerami systemu
Umożliwia analizę priorytetów nadawanych funkcjonalnościom systemu
Komponenty systemu I ich powiązania
Definiowanie wymagań techniką metody delfickiej wymaga zaangażowania ekspertów
Prawda
Fałsz
Kategorią ryzyka projektowego którą powinniśmy zarządzać w pierwszej kolejności jest
Ryzyko związane z klientami I użytkownikami systemu
Ryzyko wykonania projektu
Ryzyko wynikające ze środowiska projektu
Zakres I wymagania dla projektu
Wdrożenie systemu polegające na udostępnieniu nowego systemu bez wycofania poprzednio działającego to konwencja:
Bezpośrednia
Pilotowa
Równoległa
Etapowa
Baza danych jest przykładem komponentu :
Pamięciowego
Zarządzającego
Obliczeniowego
Kontrolera
W modelu CMM przejście na kolejny stopień wymaga stworzenia I stosowania procedur dla działań określonych na tym poziomie
Prawda
Fałsz
W modelu MoSCoW , C określa :
Wymagania o wysokim priorytecie realizacji
Wymagania, które zostaną zaimplementowane jeśli starczy czasu
Wymagania kluczowe
Wymagania dla kolejnej wersji systemu
Model CMM określa
Podejście do zarządzania zmianą zarówno w wymaganiach, jak I przy wersjonowaniu oprogramowania
Podejście do weryfikacji jakości oprogramowania
Sposobów na zmniejszenie kompleksowości oprogramowania w celu zwiększenia jakości
Stopień dojrzałości firmy w zakresie procesu tworzenia oprogramowania
W regule 60-15-25 w tworzeniu systemów informatycznych, 15 związane jest z :
Zasobami poświęconymi na projektowanie
Czasem poświęconym na projektowanie
Zasobami poświęconymi na implementację
Czasem poświęconym na implementację
Software Architecture Document może zawierać
Wszystkie odpowiedzi są prawidłowe
Opis podjętych decyzji architektonicznych
Informację o wyborach technologicznych dla systemu
Architekturę systemu z perspektywy programisty
Reengineering dotyczy
Dokonywania krytycznych zmian w systemie w celu zmniejszenia kompleksowości
Sprawdzenia zmian w kodzie (o ile projekt różni się od implementacji)
Identyfikacji komponentów systemu I ich powiązań
Pielęgnowania kodu, w tym utrzymania dokumentacji
Celem prowadzenia oceny architektury, przykładowo z wykorzystaniem metod ATAM czy ARID jest wystawienie architekturze oceny odnośnie stopnia zgodności architektury z wymaganiami
Prawda
Fałsz
Które ze stwierdzeń są zawarte w Manifeście Agile?
Narzędzia I proces są ważniejsze niż negocjacja warunków kontraktu
Wszystkie odpowiedzi są prawidłowe
Współpraca z klientem jest ważniejsza od negocjacji warunków kontraktu
Drobiazgowe plany są warunkiem skutecznego przeprowadzenia projektu
ABC (Architecture Business Cycle) uwzględnia:
Standaryzację metodyk w ramach tworzenia systemów informatycznych
Budowanie doświadczenia przez daną organizację
Wszystkie odpowiedzi są prawidłowe
Oddziaływanie architektury nowego systemu na systemy już istniejące w organizacji
Architektura uwzględnia
Powiązania między komponentami
Interfejsy
Komponenty I ich funkcjonalność
Wszystkie odpowiedzi są prawidłowe
Spełnienie wymagań użytkownika
W przypadku powiązania między komponentami polegającego na wywołaniu procedury przez jeden komponent na drugim komponencie, komunikacja tę można określić:
Synchroniczną
Jednostronna
Asynchroniczną
Rozwijanie projektu architektury w Rational Unified Process jest aktywnością realizowaną w ramach fazy:
Transition (wdrożenie)
Inception (faza wstępna)
Construction (konstrukcja)
Elaboration (uszczegółowienie)
W Modelu Walston-Felix w ocenie kosztów tworzenia oprogramowania:
Wykorzystuje się ekspertów w celu oszacowania liczby osobomiesięcy niezbędnych do opracowania systemu
Stosuje się metody ilościowe polegające na ocenie pracochłonności implementacji komponentów systemu
Oszacowano liczbę linii kodu na osobomiesiąc, a koszt stworzenia oprogramowania jest związany z estymacją linii kodu dla nowego rozwiązania
Nie bierze się pod uwagę doświadczenia członków zespołu projektowego
Specyfikacja wymagań użytkownika na pewno NIE zawiera:
Decyzji architektonicznych
Definicji wymagań użytkownika
Wizji systemu
Scenariuszy rozwojowych systemu
Na czym polega takie projektowanie systemu, by tworzyć komponenty możliwe dla ponownego wykorzystania?
Na wykorzystaniu powszechnie znanej metodyki np. RUP dla pracowania systemu wysokiej jakości
Na projektowaniu systemu w taki sposób, aby zapewnić uniwersalność rozwiązania końcowego
Na wcześniejszym stworzeniu repozytorium komponentów, a także znajomości komponentów, jakie się w nim znajdują
Na przeprowadzeniu analizy wymagań dla więcej niż jednego systemu w celu zapewnienia uniwersalności tworzonych komponentów
W przypadku jakiego oprogramowania w szczególności warto stosować techniki, jakie proponuje projektowanie systemów (Software Engineering)? Proszę o wybranie najpełniejsze odpowiedzi
Projekty naukowe
Systemy tworzone z wykorzystaniem 4GL
Projekty o dużej skali, wymagające kompleksowego zarządzania
Każda z odpowiedzi jest prawidłowa
Dbałość o oprogramowanie I zarządzanie spójnością programowania jest istotą którego z widoków w Modelu 4+1?
Logicznego
Procesowego
Fizycznego
Use Case’ow
Implementacyjnego
Problemy, które doprowadziły do powstania Software Engineering to:
Brak ról dla osób uczestniczących w procesie tworzenia oprogramowania
Kryzys oprogramowania I „zimna wojna”
Poszukiwanie oszczędności w procesach tworzenia oprogramowania
Każda z odpowiedzi jest prawidłowa
Jeśli elementy komponentu powinny być wywoływane w określonym porządku to mamy do czynienia:
Kohezją sekwencyjną
Kohezją proceduralną
Kohezją temporalną
Kohezją logiczną
W trakcie White box testing:
Analizujemy wymagania I specyfikacje I na tej podstawie determinujemy parametry wejściowe I oczekiwane (z działania programu) dane wyjściowe
Analizujemy zgodność opracowanego systemu z projektem
Interesują nas jedynie parametry wejściowe I wyjściowe, które porównujemy z rezultatami uzyskanymi z programu
Wnikamy w działanie programu
Dekompozycja funkcjonalna jest podejściem do projektowania systemów informatycznych, które:
Wykorzystując podejście dziel I rządź, nie bierze pod uwagę couplingu
Bazuje na diagramach przepływu danych
Dąży do tego by struktura systemu jak najbardziej przypominała graf
Wykorzystuje pojęcie abstrakcji
W trakcie obsługi Change Request zespół projektowy nie będzie dokonywał:
Testowania nowego fragmentu systemu
Planowania tzw. Release (czyli wypuszczenia kolejnej wersji systemu)
Klasyfikacji według typu utrzymania I rodzaju zmiany
Analizy wpływu zmiany na organizację
Wymaganiem pozafunkcjonalnym NIE jest:
Posiadanie dokumentacji
Użyteczność
Istnienie help desku
Baza danych
Różnica między LEAN a MVP polega na:
Horyzontalnym podejściu do tworzenia systemu w LEAN I iteracyjnym w MVP
Podejściu do rodzaju rozwiązania (prototypu) oferowanego użytkownikowi
Konieczności lub jej braku przeprowadzenia testów rozwiązania z użytkownikiem
Ilości zasobów niezbędnych do stworzenia pierwszej wersji prototypu
Zawsze pozytywne, w odniesieniu do satysfakcji jaką osiąga użytkownik z realizacji wymagania (i bez negatywnego wpływu na tę satysfakcję) są wymagania, które:
Są użyteczne
Są atrakcyjne
Są obojętne
Muszą być
Walidacja systemu informatycznego polega na:
Atestowaniu oprogramowania
Wszystkie odpowiedzi są prawidłowe
Określeniu zgodności systemu z wyspecyfikowanymi wymaganiami
Przeprowadzeniu spotkań z użytkownikiem, który zamówił lub będzie korzystał z systemu
Interoperacyjność czyli możliwość współpracy z systemem określa brak możliwości dostępu osób niepowołanych do danych lub systemu
Prawda
Fałsz
Zasadniczą różnicą między modelem Boehma a modelem prototypowania jest:
Wprowadzenie fazy weryfikacji
Wszystkie odpowiedzi są prawidłowe
Konstruowanie prototypu w sposób przyrostowy, a nie “do wyrzucenia”
Uwzględnienie fazy analizy ryzyka
Zgodnie z zasadą Stevensa, gdy zdanie zawiera słowa powiązane z czasem (najpierw, potem, …) to mamy do czynienia z:
Tylko kohezją temporalną
Tylko kohezją komunikacyjną
Kohezją sekwencyjną lub komunikacyjną
Kohezją sekwencyjną lub temporalną
Metodyka, w której rozwój produktu podzielony jest na mniejsze, trwające od dwóch do sześciu tygodni, fazy zwane sprintami to:
EXtreme Programming
Rapid Application Development
SCRUM
Dynamic System Development Method
Model 4+1 określa:
W warstwie procesu powiązanie tworzonego oprogramowania z istniejącą infrastrukturą fizyczną
Metodykę analizy architektury
Wszystkie odpowiedzi są prawidłowe
Widoki różnych grup użytkowników na architekturę systemu
Projektowanie Systemów Informatycznych dotyczy (wybierz najpełniejszą odpowiedź)
Tworzenia dowolnego systemu informatycznego
Tworzenia dowolnego systemu informatycznego przy wykorzystaniu technik inżynieryjnych
Tworzenia systemów informatycznych dla wojskowości przy wykorzystaniu technik inżynieryjnych
Tworzenia jedynie dużych systemów informatycznych
Rezultatem Structured Analysis na pewno NIE jest/są:
Diagramy DFD
Minispecyfikacje
Model logiczny systemu
Słownik
Model struktury systemu
Przykładem metod Agile NIE jest:
Rapid application development (RAD)
Extreme programming (XP)
Model spiralny
Model V
Czy Janeczek używa zabezpieczenia?
NIE
Oczywiście, że nie
XD
Nein
Inaczej Janeczek
Bay Leaf
Poskramiacz Lisów
Nemeczek
Janko Muzykant
{"name":"PSI", "url":"https://www.quiz-maker.com/QPREVIEW","txt":"Test your knowledge on architectural design and quality assessment methodologies with our comprehensive PSI quiz. This interactive quiz covers fundamental concepts in software engineering, focusing on principles such as coupling, cohesion, and design quality.Topics include:Architectural styles and decisionsQuality assessment modelsSoftware development methodologiesUsability and functional requirements","img":"https:/images/course2.png"}