1

1. Omów przedmiot i zakres inżynierii oprogramowania.

Inżynieria   oprogramowania   to   dziedzina   inżynierii   systemów   zajmująca   się   wszelkimi   aspektami
produkcji oprogramowania: od analizy i określenia wymagań, przez projektowanie i wdrożenie, aż do
ewolucji gotowego oprogramowania. Podczas gdy informatyka zajmuje się teoretycznymi aspektami
produkcji oprogramowania, inżynieria oprogramowania koncentruje się na stronie praktycznej.
W inżynierii oprogramowania proces produkcji oprogramowania  dzieli się na pewne fazy, typowy
podział to:
1.   specyfikacja   -   na   tym   etapie   następuje   określenie   i   ustalenie   wymagań,   które   musi   spełniać
oprogramowanie

2. projektowanie - ustalenie ogólnej architektury systemu, wymagań dla poszczególnych jego
składowych

3. implementacja - realizacja ustalonej architektury poprzez implementację składowych (modułów) i
połączeń

między

nimi.

4. integracja - zintegrowanie poszczególnych składowych w jeden system, testowanie całego systemu
5. ewolucja - uruchomienie systemu, usuwanie wykrytych podczas jego używania błędów, rozszerzanie
systemu

2. Omów zagadnienie języka programowania i semiotyki języka programowania.

Semiotyka - jeden z trzech głównych (obok logiki formalnej i metodologii nauk) działów logiki, sam
dzielący się na semantykę, pragmatykę i syntaktykę. Podział semiotyki na trzy główne działy pochodzi
od   Charlesa   W.   Morrisa.   Semiotyka   logiczna   stanowi   ogólną   teorię   znaków,   zwłaszcza   znaków
językowych – wyrażeń.
Semantyka bada relacje semantyczne, tj. związki między znakami, a rzeczywistością, tym, do czego
odnoszą   się   znaki.   Syntaktyka   bada   relacje   syntaktyczne,   tj.   relacje   zachodzące   między   samymi
znakami. Nie są to jednak wszystkie relacje zachodzące wewnątrz języka, ale jedynie te, które mają
charakter formalny - a więc niezależne od znaczenia wyrażeń, między którymi zachodzą. Pragmatyka,
która bada relacje pragmatyczne, zachodzące między znakiem a jego użytkownikami (nadawcami i
odbiorcami),   ma   częściowo   nieuregulowany   status   -   istnieje   wiele   prób   uczynienia   z   niej   nauki
formalnej   na   wzór   semantyki   i   syntaktyki,   może   ona   jednak   być   uprawiana   również   jako   nauka
empiryczna   mówiąca   o   ludzkim   zachowaniu   i   łącząca   w   sobie   elementy   psychologii,   socjologii   i
wiedzy o kulturze.

3. Omów zagadnienie i skutki tzw. „kryzysu oprogramowania”.

Kryzys oprogramowania (ang. software crisis) — zjawisko dostrzeżone już w latach 60. Polega na
powiększającej się rozbieżności między mocą obliczeniową sprzętu komputerowego a efektywnością
produkcji oprogramowania. Wysiłki informatyków zmierzają do optymalizacji procesu wytwarzania
oprogramowania poprzez stosowanie odpowiednich metod i technik szczegółowych w tym zakresie.

4. Omów przykładowe źródła złożoności projektu informatycznego.

Najczęstsze   ryzyko   związane   z   realizacją   projektów   IT   wynika   z   braku   kompetencji   samych
użytkowników, opóźnień w prowadzeniu przedsięwzięcia oraz źle zaplanowanego i przekroczonego
budżetu. Istnieje również grupa ryzyk wiążących się z nagłą zmianą priorytetów, reorganizacją struktur
i zasobów oraz rotacją ludzi w zespołach. W przypadku zarządzania ryzykiem szefowie IT stawiali
przede   wszystkim   na   własne   siły.   Jedynie   nieliczni   decydowali   się   na   wybór   zewnętrznego
doradcy.Kolejna   przeszkoda   wynika   z   długiego   procesu   decyzyjnego   oraz   oporu   kierownictwa
wyższego szczebla.

5. Omów sposoby opanowywania złożoności projektu informatycznego.

Aby walczyc ze zjawiskiem zlozonosci projektu, stosuje sie:
ZASADE DEKOMPOZYCJI
Czyli rozdzielenie złożonego problemu na podproblemy,
ZASADE ABSTRAKCJI
Czyli eliminacja,mniej istotnych szczegółów rozważanego przedmiotuwyodrębnianie cech wspólnych
pewnego zbioru bytów i wprowadzaniu pojęć oznaczających te cechy.
ZASADE PONOWNEGO UZYCIA
Czyli wykorzystanie wcześniej wytworzonych schematów, metod,
ZASADE SPRZYJANIA NATURALNYM LUDZKIM WLASNOSCIOM
Czyli dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich
zdolnosci

6. Omów zagadnienie modelowania pojęciowego w projekcie informatycznym.

Pojęcia modelu pojęciowego odnosi się do procesów myślowych i wyobrażeń towarzyszących pracy
nad oprogramowaniem. Jest wspomagane przez środki wzmacniające wyobraźnię. Służą one do
przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości

7. Co to jest metodyka prowadzenia projektu informatycznego?

Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do
analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do projektowania pojęciowego,
logicznego i/lub fizycznego.

8. Omów następujący model cyklu życia oprogramowania: … nazwa modelu

Model kaskadowy: zawiera ciag czynnosci wykonywanych sekwencyjnie przy tworzeniu
oprogramowania:
-okreslenie wymagan
-analiza
-projektowanie
-implementacja
-testowanie
-konserwacja

wady: Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac
Wysoki koszt błędów popełnionych we wczesnych fazach
Długa przerwa w kontaktach z klientem

Wytwarzanie ewolucyjne

polega na:
opracowaniu wstępnej implementacji,
pokazaniu jej użytkownikowi z prośbą o komentarze
oraz udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu;
wyroznia sie tworzenie badawcze (praca z klientem) oraz prototypowanie (praca z elementami systemu
budzacymi watpliwosci)

prototypowanie:
Sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań.
Zalecany w przypadku, gdy określenie początkowych wymagań jest stosunkowo łatwe.
fazy
ogólne określenie wymagań
budowa prototypu
weryfikacja prototypu przez klienta
pełne określenie wymagań
realizacja pełnego systemu zgodnie z modelem kaskadowym

model V
polega na wytwrzaniu rownlolegle oprogramowania i prowadzeniu testow akceptacji, poszczegolne
elementy systemu sa badane od razu po wytworzeniu, praca polega na podziale systemu na
podsystemy, a te na poszczegolne zadania, co robi jeden z zespolow, a drugi zespol odpowiada
wylacznie za ocene i testowanie systemu. testy odbywaja sie od zadan, potem przechodza do
testowania podsystemow, a nastepnie testowany jest pelny system.

model spiralny
opiera sie na ewolucyjym projekcie, ktory jest poczatkowo planowany, nastepnie nastepuje analiza
ryzyka systemu, konstrukcja (czesto odbywa sie zgodnie z modelem kaskadowym) a potem klient
testuje system, informuje, co wymaga zmian i poprawek, i zgodnie z nimi caly cykl rozpoczyna sie od
poczatku, w kolejnym obrocie petli do istniejacego systemu wprowadzane sa poprawki dopoki klient
nie zaakceptuje systemu.

9. Omów zadania kierownictwa przedsięwzięcia informatycznego w cyklu wytwórczym
oprogramowania.

Podstawowe zadania kierownictwa przedsięwzięcia informatycznego:

- Opracowanie propozycji dotyczących sposobu prowadzenia przedsięwzięcia
- Kosztorysowanie przedsięwzięcia
- Planowanie i harmonogramowanie przedsięwzięcia
- Monitorowanie i kontrolowanie realizacji przedsięwzięcia
- Dobór i ocena personelu
- Opracowanie i prezentowanie sprawozdań dla kierownictwa wyższego szczebla

10. Omów podstawowe czynniki psychologiczne w procesie wytwórczym i rodzaje osobowości
twórców oprogramowania

Czynniki te wynikają z faktu, że oprogramowanie jest używane i tworzone przez ludzi.
Użytkowanie - implikuje zasady tworzenia interfejsu użytkownika i dokumentacji użytkowej,
Tworzenie - zagadnienia psychologiczne odgrywające rolę w tworzeniu oprogramowania.

Elementy ludzkiej inteligencji:

Umiejętność całościowego (syntetycznego) spojrzenia na problem.
Posługiwanie się wiedzą płynącą z doświadczenia, a więc stosowania nieścisłych zasad wnioskowania
na bazie wcześniejszych doświadczeń.

Istnieją ogromne różnice w predyspozycjach osób dotyczące ich efektywności w produkcji
oprogramowania.
Testy osobowości:
metody określenia, czy dana osoba posiada cechy przydatne na danym stanowisku.
Stosowanie testów osobowości wiąże się z następującymi trudnościami:

Osobowość ludzka ma charakter dynamiczny (zmienia się). Wieloletnia praktyka zawodowa nie
pozostaje bez wpływu na osobowość.

Różne zadania mogą wymagać różnych cech osobowości. Inne powinien posiadać analityk (kontakt z
klientem), inne zaś programista lub osoba testująca oprogramowanie. Ponadto, metody inżynierii
oprogramowania ulegają zmianie, co pociąga za sobą inny stosunek pożądanych cech osobowości do
aktualnych zadań.

Osoby poddane testom będą starały się raczej odgadnąć pożądaną przez testujących odpowiedź niż
odpowiadać zgodnie ze stanem faktycznym. Test nie będzie więc odzwierciedlał cech osobowości
osoby, lecz raczej to, jak ta osoba wyobraża sobie cele i kryteria testowania oraz cechy pożądane przez
pracodawcę

11. Omów cechy dobrego inżyniera oprogramowania i sposoby zorientowania na pracę
w cyklu wytwórczym oprogramowania.

Umiejętność pracy w stresie. W pracy często zdarzają się okresy wymagające szybkiego wykonania
złożonych zadań. Dla większości osób niewielki stres działa mobilizująco. Po przekroczeniu jednak
pewnego progu następuje spadek możliwości danej osoby. Próg ten jest różny dla różnych osób.

Zdolności adaptacyjne. Informatyka jest jedną z najszybciej zmieniających się dziedzin. Ocenia się, że
7-9 miesięcy przynosi w informatyce zmiany, które w innych dziedzinach zajmują 5-7 lat. Oznacza to
konieczność stałego kształcenia dla wszystkich inżynierów oprogramowania - stałe poznawanie
nowych narzędzi, sprzętu, oprogramowania, technologii, metod, sposobów pracy. Niestety, nie
wszyscy to tempo wytrzymują.

Uśpienie, zajmowanie się jednym problemem w jednym środowisku przez lata jest w informatyce
bardzo groźne!

Wyróżnia się następujące typy psychologiczne:

1. Zorientowani na zadania (task-oriented). Osoby samowystarczalne, zdolne, zamknięte, agresywne,
lubiące współzawodnictwo, niezależne.

2. Zorientowani na siebie (self-oriented). Osoby niezgodne, dogmatyczne, agresywne, zamknięte,
lubiące współzawodnictwo, zazdrosne.

3. Zorientowani na interakcję (interaction-oriented). Osoby nieagresywne, o niewielkiej potrzebie
autonomii i indywidualnych osiągnięć, pomocne, przyjazne.

Osoby typu 1 są efektywne, o ile pracują w pojedynkę. Zespół złożony z takich osób może być jednak
nieefektywny. Lepsze wyniki dają zespoły złożone z typów 3. Typ 1 i 2 może być także efektywny w
zespole, o ile jest odpowiednio motywowany przez kierownictwo. Typy 3 są konieczne w fazie
wstępnej wymagającej intensywnej interakcji z klientem.

12. Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według Prince2

Projekt, to sposób prowadzenia przedsięwzięć gospodarczych zmierzający do wytworzenia produktu
uzasadnionego biznesowo, w ramach określonego czasu, budżetu, z odpowiednią strukturą
organizacyjną , rolami i zakresami odpowiedzialności.

Wymiary zarządzania: produkt, Koszt Hormonogram Jakość.
Poszczególne wymiary zarządzania projektem mają na siebie istotny wpływ. Powinny być one
analizowane przez kierownika projektu łącznie (również ocena ryzyka)

Przez produkty projektu rozumie się wszystkie jego elementy, które mogą powstać w wyniku jego
realizacji

Często spotykaną formą prezentacji harmonogramu są na przykład tabele lub arkusze kalkulacyjne, jak
również wykresy Gantta

Budżet projektu stanowi zestawienie kosztów realizacji projektu.

Wymiar jakości dotyczy:
- oceny zarówno poszczególnych produktów projektowych:
- dokumentacji,
- oprogramowania,
- platformy techniczno-systemowej itp.

13. Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń
Prince2.

Sponsor Projektu-członek zarządu klienta lub jego bezpośredni przedstawiciel,odpowiedzialny za
finansowanie całego przedsięwzięcia mają prawo do wglądu w projekt i podejamowania decyzji na
temat jego dalszego rozwoju
Rada Projektu- zawiera w swoim ciele reprezentację wszystkich uczestników projektu, takich jak:
Sponsor, użytkownicy, dostawcy,mianowanie Szefów Projektu,okresowa i etapowa ocena stanu
projektu i zatwierdzanie planów dalszych prac,rozstrzyganie sporów występujących na szczeblu
Szefów Projektu,zatwierdzanie Wniosków o Zmianę w zakresie funkcjonalnym i niefunkcjonalnym
projektu,zatwierdzanie akceptacji kolejnych produktów projektu
Szefowie projektu-prowadzą i gromadzą dokumentację projektu,zapewniają warunki pracy zespołów
realizacyjnych,realizują zatwierdzone zmiany,w zależności od potrzeb zajmują eskalacją
odpowiednich problemów
Szef Jakości jest współpracuje z Szefami Projektu i sprawdza jakość całego projektu poniewarz
podlegają plany i dokumentacja projektu wraz z produkatami i ich testami.
Komitet Kontroli Zmian składa się z przedstawicieli zarówno dostawcy jak i klienta. Jego skład
wyznacza Rada Projektu
Komitet Akceptacyjny składa się przeważnie z przedstawicieli obu stron, często jednak spotyka się w
nim wyłącznie przedstawicieli klienta (przyjęcie lub odrzucenie produktu)

Sekretariat/administracja biura projektu- prowadzi archiwum projektu (zawiera się w nim biblioteka
projektu, zbiory raportów oraz zajmuje się rozliczeniami finansowymi)

Zespoły Realizacyjne- realizują projekt, szefami sa przeważnie osoby doświadczone w zakresie tematu
projektu

14. Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według metodyki
PMI.

Zakres-projekt zawiera tylko to co potrzeba
inicjowanie faz
projektu
planowanie zakresu
definiowanie zakresu
weryfikacja zakresu
kontrola zmian zakresu

Koszt-obejmuje procesy wymagane do zapewnienia, że projekt zostanie ukończony w ramach
zaakceptowanego budżetu
Czas-projektu obejmuje procesy wymagane do zapewnienia przestrzegania przez zespół projektowy
ustalonych granic czasowych dla poszczególnych czynności w projekcie
Jakość-obejmuje procesy wymagane do zapewnienia zaspokojenia przez rezultaty projektu tych
potrzeb, dla których został on powołany
Komunikacja-obejmuje procesy służące zapewnieniu terminowego i właściwego tworzenia,
gromadzenia, rozpowszechniania, przechowywania i usuwania informacji niezbędnej do efektywnego
zarządzania projektem
Integracja-obejmuje procesy wymagane do zapewnienia poprawnej koordynacji wszystkich elementów
projektu
Ryzyko-obejmuje procesy identyfikacji, analizowania i reakcji na zaistnienie czynników ryzyka w
projekcie
Ludzie-obejmuje procesy ułatwiające efektywne wykorzystanie ludzi w projekcie
Zaopatrywanie-obejmuje zdobywanie dóbr i usług spoza organizacji wykonującej projekt

15. Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń
metodyki Chestra SBS.

Silna pozycja Kierownika Projektu (Szefa Projektu),
zakres projektu i zakres produktu jest określany przez Architekta
Systemowego i Architekta Biznesowego,
Menedżer Jakości podlega pod Szefa Projektu
Menedżer Konfiguracji nie jest już składową administracji projektu
wyróżniono obszary dokumentacji i testów

16. Porównaj zalecenia Prince2, PMI i Chestra SBS w zakresie obszarów zarządzania projektem
informatycznym i organizacji biura projektu informatycznego.

PRINCE2:
*dobre*
-Stosowanie tej metodyki zapewnia wysoką standaryzację i powtarzalność projektów o wspólnym
podejściu, terminologii i dokumentacji. Zapewnia to możliwość doskonalenia kompetencji.
-Metodyka w sposób racjonalny opiera się na najlepszych praktykach w zarządzaniu projektami
-Sprawuje kontrolę nad startem, realizacją i końcem projektu
-Jej stosowanie nie wymaga opłat autorskich

*złe*
-zbyt pracochłonne w zastosowaniu do małych projektów
-ciągła wymiana informacji powoduje pojawienie się bezproduktywnych
spotkań zabierających czas niezbędny na rzeczywistą pracę

17. Omów zagadnienie zarządzania konfiguracją w przedsięwzięciu informatycznym na
podstawie metodyki RUP.

Zarządzania konfiguracją (configuration management) - jest odpowiedzialne za systematyczne
strukturalizowanie produktów. Artefakty takie jak dokumenty i modele muszą być wersjonowane
(version control) a zmiany muszą być widoczne. W skład zarządzania konfiguracją wchodzi także
utrzymywanie rejestru zależności pomiędzy artefaktami, tak, aby wszystkie powiązane części były
uaktualniane wraz ze zmianami.

18. Omów zakres działania tzw. „inżynierii wymagań” w procesie wytwórczym oprogramowania.

W procesie inżynierii wymagań możemy wyróżnić cztery główne fazy:
1. Studium wykonalności,
- Wynikiem tego studium powinien być raport, który zaleca albo nie zaleca kontynuacji procesu
inżynierii wymagań i tworzenia systemu.
- Studium wykonalności to krótkie, skumulowane opracowanie, w którym staramy się odpowiedzieć na
kilka pytań:
a. Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa?
b. Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego
budżetu i ograniczeń czasowych?
c. Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano?
2. Określenie i analiza wymagań,
- W trakcie tej czynności techniczni budowniczowie oprogramowania pracują z klientem i
użytkownikami systemu nad badaniem dziedziny zastosowania i usług, które system ma oferować,
pożądanej efektywności, ograniczeniach sprzętowych itd.
3. specyfikowanie wymagań,
- to częściowo ustrukturalizowany zapis wykorzystujący zarówno język naturalny, jak i proste,
częściowo przynajmniej sformalizowane notacje.
4. zatwierdzanie wymagań;
- Polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik
- Błędy w wymaganiach kosztują tak dużo, że warto te wymagania zatwierdzać
Poprawianie błędów w wymaganiach może kosztować sto razy więcej niż poprawianie błędów w
implementacji Inżynieria wymagań ma na celu ma na celu określenie, jakich usług wymaga się od
systemu i jakim ograniczeniom podlega tworzenie i działanie oprogramowania;

19. Omów podstawowe metody rozpoznawania wymagań i cechy jakościowego dobrego opisu
wymagań.

Podstawowe metody rozpoznania wymagań:
- Wywiady i przeglądy. Wywiady powinny być przygotowane (w postaci listy pytań) i podzielone na
odrębne zagadnienia. Podział powinien przykrywać całość tematu i powinny być przeprowadzone na
reprezentatywnej grupie użytkowników. Wywiady powinny doprowadzić do szerokiej zgody i
akceptacji projektu.
- Studia na istniejącym oprogramowaniem. Dość często nowe oprogramowanie zastępuje stare. Studia
powinny ustalić wszystkie dobre i złe strony starego oprogramowania.
- Studia wymagań systemowych. Dotyczy sytuacji, kiedy nowy system ma być częścią większego
systemu.
- Studia osiągalności. Określenie realistycznych celów systemu i metod ich osiągnięcia.
- Prototypowanie. Zbudowanie prototypu systemu działającego w zmniejszonej skali, z uproszczonymi
interfejsami.

Cechy jakościowego dobrego opisu wymagań:
Dobry opis wymagań powinien:
- Być kompletny oraz niesprzeczny.
- Opisywać zewnętrzne zachowanie się systemu a nie sposób jego realizacji.
- Obejmować ograniczenia przy jakich musi pracować system.
- Być łatwy w modyfikacji.
- Brać pod uwagę przyszłe możliwe zmiany wymagań wobec systemu.
- Opisywać zachowanie systemu w niepożądanych lub skrajnych sytuacjach

20. Omów główne klasy wymagań na system informatyczny. Podaj przykłady takich
wymagań.

Wymagania funkcjonalne
– Są stwierdzeniami, 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ć.
– Mogą być również wykonywane przy użyciu systemów zewnętrznych.
Przykład:

a) Użytkownik będzie mógł przeszukać zbiór wszystkich baz danych lub wybrać tylko ich podzbiór.
b) System udostępni odpowiednie narzędzia do oglądania, aby użytkownik mógł czytać dokumenty z
magazynu.

Wymagania niefunkcjonalne
– To ograniczenia usług i funkcji systemu.
– Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.
Przykład:
a) System powinien być łatwy w użyciu dla doświadczonych kontrolerów, a sposób jego organizacji
powinien zmniejszać liczbę błędów użytkownika.
b) Doświadczeni kontrolerzy powinni móc używać wszystkich funkcji systemu po szkoleniu
trwającym dwie godziny. Po tym szkoleniu średnia liczba błędów robionych przez doświadczonych
użytkowników nie powinna przekroczyć dwóch dziennie.

Wymagania dziedzinowe
– Są wyrażone za pomocą języka specyficznego dla dziedziny zastosowania;
– Pochodzą z dziedziny zastosowania systemu - odzwierciedlają jej charakterystykę.
– Mogą być funkcjonalne lub niefunkcjonalne..
Przykład: wymagania stawiane systemowi biblioteki
a) Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego
podstawą jest standard Z39.50.
b) względu na ochronę praw autorskich niektóre dokumenty należy składać natychmiast po ich
otrzymaniu. Zależnie od wymagań użytkownika, dokumenty te będą drukowane lokalnie na serwerze
systemowym i przekazywane do rąk czytelnika albo wysyłane na drukarkę sieciową.

21. Omów i podaj przykłady wymagań funkcjonalnych dla systemu informatycznego.

Wymagania funkcjonalne:
Opisują funkcje (czynności, operacje) wykonywane przez system.
Funkcje te mogą być również wykonywane przy użyciu systemów zewnętrznych.
Określenie wymagań funkcjonalnych obejmuje następujące kwestie:
Określenie wszystkich rodzajów użytkowników, którzy będą korzystać z systemu.
Określenie wszystkich rodzajów użytkowników, którzy są niezbędni do działania systemu (obsługa,
wprowadzanie danych, administracja).
Dla każdego rodzaju użytkownika określenie funkcji systemu oraz sposobów korzystania z
planowanego systemu.
Określenie systemów zewnętrznych (obcych baz danych, sieci, Internetu), które będą wykorzystywane
podczas działania systemu.
Ustalenie struktur organizacyjnych, przepisów prawnych, statutów, zarządzeń, instrukcji, itd., które
pośrednio lub bezpośrednio
określają funkcje wykonywane przez planowany system.

22. Omów i podaj przykłady wymagań niefunkcjonalnych dla systemu informatycznego.

Wymagania niefunkcjonalne:
Opisują ograniczenia, przy których system ma realizować swoje funkcje.
Wymagania dotyczące produktu.
Np. musi istnieć możliwość operowania z systemem wyłącznie za pomocą klawiatury.
Wymagania dotyczące procesu.
Np. proces realizacji harmonogramowania zleceń musi być zgodny ze standardem opisanym w
dokumencie XXXA/96.
Wymagania zewnętrzne.
Np. system harmonogramowania musi współpracować z bazą danych systemu komputerowego działu
marketingu opisaną w dokumencie YYYB/95.
Niedopuszczalne są jakiekolwiek zmiany w strukturze tej bazy.
Są to np: wymagania jakościowe (określają szczegółowe oczekiwania co do wydajności),
technologiczne, bezpieczeństwa

Mogą definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia i reprezentacje
danych używane przez interfejsy systemu.
Wymagania niefunkcjonalne wynikają z:
potrzeb użytkownika,
ograniczeń budżetowych,
strategii firmy,
konieczności współpracy z innymi systemami sprzętu lub oprogramowania,
czynników zewnętrznych.

23. Omów metody specyfikacji wymagań dla systemów informatycznych.

Metody specyfikacji wymagań:
Język naturalny - najczęściej stosowany. Wady: niejednoznaczność powodująca różne rozumienie tego
samego tekstu; elastyczność, powodująca wyrazić te same treści na wiele sposobów. Utrudnia to
wykrycie powiązanych wymagań i powoduje trudności w wykryciu sprzeczności.
Formalizm matematyczny. Stosuje się rzadko (dla specyficznych celów).
Język naturalny strukturalny. Język naturalny z ograniczonym słownictwem i składnią. Tematy i
zagadnienia wyspecyfikowane w punktach i podpunktach.
Tablice, formularze. Wyspecyfikowanie wymagań w postaci (zwykle dwuwymiarowych) tablic,
kojarzących różne aspekty (np. tablica ustalająca zależność pomiędzy typem użytkownika i rodzajem
usługi).
Diagramy blokowe: forma graficzna pokazująca cykl przetwarzania.
Diagramy kontekstowe: ukazują system w postaci jednego bloku oraz jego powiązania z otoczeniem,
wejściem i wyjściem.
Diagramy przypadków użycia: poglądowy sposób przedstawienia aktorów i funkcji systemu.

24. Omów przykładowy zakres treści dokumentu opisującego wymagania na system
informatyczny.

Streszczenie (maksymalnie 200 słów)
Spis treści
Status dokumentu (autorzy, firmy, daty, podpisy, itd.)
Zmiany w stosunku do wersji poprzedniej
1. Wstęp
1.1. Cel
1.2. Zakres

1.3. Definicje, akronimy i skróty
1.4. Referencje, odsyłacze do innych dokumentów
1.5. Krótki przegląd
2. Ogólny opis
2.1. Walory użytkowe i przydatność projektowanego systemu
2.2. Ogólne możliwości projektowanego systemu
2.3. Ogólne ograniczenia
2.4. Charakterystyka użytkowników
2.5. Środowisko operacyjne
2.6. Założenia i zależności
3. Specyficzne wymagania
3.1. Wymagania funkcjonalne (funkcje systemu)
3.2. Wymagania niefunkcjonalne (ograniczenia).
Dodatki
Kolejność i numeracja punktów w przedstawionym spisie treści powinna być zachowana. W
przypadku gdy pewien punkt nie zawiera żadnej informacji należy wyraźnie to zasygnalizować przez
umieszczenie napisu „Nie dotyczy”.
Dla każdego wymagania powinien być podany powód jego wprowadzenia: cele przedsięwzięcia,
których osiągnięcie jest uwarunkowane danym wymaganiem.
Wszelki materiał nie mieszczący się w podanych punktach należy umieszczać w dodatkach.
Często spotykane dodatki:
Wymagania sprzętowe.
Wymagania dotyczące bazy danych.
Model (architektura) systemu.
Słownik terminów (użyte terminy, akronimy i skróty z wyjaśnieniem)
Indeks pomocny w wyszukiwaniu w dokumencie konkretnych informacji (dla dokumentów dłuższych
niż 80 stron)

25. Omów zakres fazy analizy w cyklu wytwórczym systemów informatycznych.

Celem fazy analizy jest ustalenie wszystkich tych czynników lub warunków w dziedzinie
przedmiotowej, w otoczeniu realizatorów projektu, w istniejących lub planowanych systemach
komputerowych, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na
realizację wymagań.
Wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych
wymagań, lecz abstrahujących od szczegółów implementacyjnych.

Czynności wykonywane w tej fazie:
Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub
problemu będącego przedmiotem projektu;
Ustalenie kontekstu projektu;
Ustalenie wymagań użytkowników;
Ustalenie wymagań organizacyjnych
Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania,
ograniczeń finansowych, ograniczeń czasowych, itd.

27. Omów przykłady nieobiektowego podejścia do analizy, projektu i implementacji systemów
informatycznych.
Analiza:
Głównym celem analizy jest wprowadzenie strukturalnej specyfikacji opisu projektu za pomocą
narzędzi modelowania:
– diagramów przepływu danych — DFD,
– diagramów obiekt-relacja-atrybut — ERD,
– diagramów przejść stanów — STD;
Wynikiem analizy jest zbudowanie następujących modeli:
– model otoczenia,
– model zachowania systemu;
Modele są opisem formalnym systemu, niezależnym od technologii, jakiej użyje się do implementacji
nowego systemu;
Na końcu etapu analizy określa się dokładniej niż w poprzednim etapie budżet projektu oraz kalkulację
kosztów i zysków;

Projektowanie:
Polega na:
– wyodrębnienie tych części modelu zachowania systemu, które będą implementowane w systemie
informatycznym;
– przydzielenie poszczególnych części specyfikacji do odpowiednich procesorów lub serwerów
(przetwarzanie rozproszone); fragmenty DFD (te, które będą implementowane) są mapowane na
zadania;
– zaprojektowanie struktury hierarchii modułów wewnątrz danego zadania;
– transformacja diagramów ERD na relacyjną bazę danych (projektowanie logiczne danych);

Implementacja:
W fazie implementacji:
– realizowane jest kodowanie i integracja modułów;
– stosuje się techniki programowania strukturalnego oraz implementacji top-down;

28. Omów przykłady obiektowego podejścia do analizy, projektu i implementacji systemów
informatycznych.
Analiza obiektowa
– opracowanie modelu obiektowego dziedziny zastosowania;
– rozpoznane obiekty odzwierciedlają byty i operacje związane z rozwiązywanym problemem;
Projektowanie obiektowe
– opracowanie modelu obiektowego systemu oprogramowania, który będzie implementacją
zidentyfikowanych wymagań;
– obiekty projektu obiektowego są związane z rozwiązaniem problemu;
Zadania w etapach fazy projektowania:
– uściślenie istniejących definicji klas, np. metod,
– dziedziczenie klas i operacji,
– szczegółowy projekt operacji wraz z przeprojektowaniem ich algorytmów,
– wprowadzenie ogólnych mechanizmów realizacji dynamiki obiektów,
– decyzje o trwałości obiektów,
– modularyzacja i ukrywanie informacji,
– optymalizacja modelu,

– dokumentacja projektu;

Programowanie obiektowe
– realizacja projektu oprogramowania za pomocą języka programowania obiektowego;
– języki obiektowe umożliwiają bezpośrednią implementację obiektów i dostarczają udogodnienia do
definiowania klas obiektów;

29. Co to jest system informatyczny i jakie są jego główne wyznaczniki jakości.

System informatyczny to złożony program komputerowy lub zespół współdziałających ze sobą
programów, przeznaczonych do wykonywania określonych funkcji: np. system operacyjny, system
zarządzania bazami danych .
Najczęściej o systemie informatycznym mówi się wtedy, gdy do zbierania, gromadzenia, przesyłania i
przetwarzania danych zastosowane są techniczne środki informatyki, a przynajmniej komputer do
przetwarzania. Zestaw technicznych środków informatyki jest przeznaczony do realizacji zadań
określonych przez system informacyjny .
Podsumowując – system informatyczny to określony obszar systemu informacyjnego danego obiektu,
obsługiwany za pomocą technicznych środków dostępnych w informatyce.

Wyznaczniki jakości systemu informatycznego:
zgodny z wymaganiami użytkownika
-niezawodny
-efektywny
-łatwy w konserwacji
-interoperacyjny (jeżeli nie jest autonomiczny)
-ergonomiczny

30. Omów podstawowe diagramy statyczne w języku IBM/Rational UML.

Diagram klas – to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach
obiektowych przez ilustrację struktury klas i zależności między nimi. Elementami występującymi w
diagramie klas są:
-klasy
-interfejsy
-grupy współdziałania
Pomiędzy elementami występującymi na diagramie klas występują związki:
-zależności
-generalizacji
-asocjacji
-agregacji
Diagram klas jest najczęściej wykorzystywanym diagramem w notacji UML.

Diagram obiektów - zamiast klas pokazują instancje. Przydają się do wyjaśniania drobnych elementów
ze skomplikowanymi relacjami, zwłaszcza rekurencyjnymi.Każdy prostokąt na diagramie obiektów
odpowiada pojedynczej instancji. Nazwy instancji na diagramach UML są podkreślone. Nazwy klas
lub instancji mogą zostać pominięte na diagramach obiektów, pod warunkiem, że sens diagramu
pozostaje jasny.

Diagram komponentów - (zwany także diagramem implementacji) to diagram przedstawiający jeden z
aspektów modelu zgodnego z UML. Przedstawia fizyczne elementy wchodzące w skład systemu i
połączenia między nimi.

Diagram pakietów – to diagram służący do porządkowania struktury systemu. Stosowane, aby uprościć
skomplikowane diagramy klas, klasy grupujemy w pakiety. Pakiet to zbiór logicznie powiązanych
elementów UML.
Pakiety to prostokąty z małymi zakładkami na górze. Nazwa pakietu znajduje się na zakładce albo
wewnątrz prostokąta. Strzałki z przerywanymi liniami to zależności. Jeden pakiet jest zależny od
drugiego, jeśli zmiany w drugim pakiecie mogą wymusić zmiany w pierwszym.

Diagram wdrożenia - (Deployment Diagram) obrazuje konfigurację węzłów działających w czasie
wykonania i zainstalowane na nich komponenty. Odnosi się do statycznych aspektów perspektywy
wdrożeniowej. Wiąże się z diagramem komponentów, ponieważ zwykle każdy węzeł zawiera
conajmniej jeden komponent.
Diagramy wdrożenia zawierają na ogół węzły i powiązania między nimi. Są przydatne do
modelowania systemów rozproszonych i typu klient-serwer.

31. Omów podstawowe diagramy dynamiczne w języku IBM/Rational UML.
Diagram przypadków użycia
Diagramy przypadków użycia opisują, co robi system z punktu widzenia zewnętrznego obserwatora.
Eksponują to, co robi system, a nie jak to robi. Diagramy przypadków użycia pozostają w bliskim
związku ze scenariuszami.
Przypadek użycia to podsumowanie scenariuszy pojedynczego zadania lub celu. Aktor to ktoś albo coś,
co inicjuje zdarzenia związane z tym zadaniem. Aktor po prostu określa rolę, którą odgrywa człowiek
lub obiekt.
Jeden przypadek użycia może mieć wielu aktorów.
Diagramy przypadków użycia mają trzy zastosowania:
-Określanie funkcji (wymagań). Nowe przypadki użycia często generują nowe wymagania, kiedy
system jest analizowany i projekt przybiera coraz wyraźniejszy kształt.
-Komunikacja z klientami. Prostota notacji sprawia, że diagramy przypadków użycia są dobrym
sposobem porozumiewania się programistów z klientami.
-Generowanie przypadków testowych. Zbiór scenariuszy danego przypadku użycia może zasugerować
sposoby testowania tych scenariuszy.

Diagram stanów.
Obiekty cechują się zachowaniami i stanem. Stan obiektu zależy od jego bieżącej aktywności lub
warunków. Diagram stanów pokazuje możliwe stany obiektu oraz przejścia, które powodują zmianę
stanu. Stany to zaokrąglone prostokąty. Przejścia to strzałki wiodące od jednego stanu do drugiego.
Zdarzenia lub warunki wyzwalające przejścia są zapisane obok strzałek.

Diagram czynności.
Diagram czynności (Activity Diagram) to szczególny przypadek diagramu stanów, który obrazuje
strumień kolejno wykonywanych czynności.
Diagram czynności obrazuje przepływ sterowania (jest właściwie schematem blokowym). Przedstawia
sekwencyjne (ew. współbieżne) kroki procesu obliczeniowego.
Diagram czynności zawiera na ogół stany (akcji i czynności), przejścia oraz obiekty. Wykonywane

obliczenia nazywamy stanami (akcji lub czynności). Stany akcji i czynności są szczególnymi
przypadkami stanów maszyny stanowej. Diagram czynności jest rodzajem maszyny stanowej.
Tory wskazują umiejscowienie czynności. Występując na diagramie czynności są pooddzielane
pionowymi, ciągłymi liniami. Każdy tor ma unikatową nazwę.

Diagram sekwencji zdarzeń (przebiegów)
Opisują one, jak obiekty ze sobą współpracują. Diagram sekwencji to diagram interakcji, który
szczegółowo pokazuje, w jaki sposób są wykonywane operacje - jakie komunikaty są wysyłane i kiedy.
Czas upływa w miarę poruszania się w dół strony. Obiekty zaangażowane w operację są wymienione
od lewej do prawej według tego, kiedy biorą udział w sekwencji komunikatów.
Diagram współpracy (kooperacji)
Diagramy współpracy to diagramy interakcji. Dostarczają tych samych informacji co diagramy
sekwencyjne, ale skupiają się na rolach obiektów, a nie na czasach przesyłania komunikatów. Na
diagramie sekwencyjnym role obiektów są wierzchołkami, a komunikaty - liniami łączącymi
wierzchołki.
Prostokąty opisujące rolę obiektu są oznaczone nazwami klas lub obiektów (albo obiema nazwami).
Nazwy klas są poprzedzone dwukropkiem ( : ).

32. Omów podstawowe diagramy w metodyce Oracle CASE Method.

Diagram zależności
Diagram zależnosci to narzedzie do przedstawiania złożonych zależnosci miedzy przyczynami i
skutkami. Diagramy zależnosci pozwalajż odnalećź często trudną do wykrycia zależnosc problemu od
pierwotnej przyczyny. Pomagaja zilustrowac łancuchy zaleznosci i wzajemnych zaleznosci, przez co
ułatwiaja podjecie działania w odpowiednim miejscu. Pomagaja równiez w identyfikacji efektów
ubocznych tych działan.

Diagram przepływu danych - (DFD – Data Flow Diagram) jest graficzną prezentacją przepływu
danych w procesie. Na proces składają się następujące elementy:
-Funkcje — (procesy) realizują określone cele; jeśli funkcji nie można rozbić na pod-funkcje, wówczas
nosi ona nazwę elementarnej.
-Magazyny danych — trwałe lub tymczasowe składnice danych, które są argumentami dla funkcji.
-Terminatory — obiekty, które nie są częścią systemu, ale stanowią odbiorców bądź źródła danych lub
argumentów funkcji.
Przepływy — elementy pokazujące kierunek przesyłu danych (np. bajtów, znaków, pakietów..).
Diagram przepływu danych obrazuje za pomocą przepływów kierunek przepływu danych pomiędzy
funkcjami, magazynami i obiektami zewnętrznymi.

33. Porównaj następujące podejścia do analizy i projektowania systemów informatycznych: 1)
podejście: encja-związek, 2) podejście obiektowe.

/* z własnych przemyśleń*/
Model encja-związek reprezentuje dane i związki pomiędzy nimi. Podejście to pozwala na
odwzorowanie w systemie danych i powiązań pomiędzy nimi. Pozwala na analizę rodzajów danych,
ich przepływu w procesach przetwarzania, oraz na odpowiednie zaprojektowanie przechowywania
danych. Jest to podejście dobre dla systemów, których głównym zadaniem jest przetwarzanie danych i
ich przedstawianie, a także przechowywanie. Korzystne dla systemów bazodanowych.

Model obiektowy skupia się bardziej nad tym jak dane są przetwarzane, jaki jest do nich dostęp, jaka
jest wymiana danych pomiędzy obiektami. W modelu obiektowym na drugi plan przesunięte jest jak
dane są przechowywane, a także jak są reprezentowane. Znacznie istotniejsze jest kto ma do nich
dostęp, jakie obiekty biorą udział w ich przetwarzaniu i jakie metody operują na danych. Podejście to
jest korzystne dla wszystkich systemów, gdzie konieczna jest odpowiednia kontrola dostępu do
danych, poprawności danych, oraz kontrola sposobu przetwarzania.

34. Omów zagadnienie audytu w procesie wytwórczym systemów informatycznych.

Audytem nazywany jest niezależny przegląd i ocenę jakości oprogramowania, która zapewnia
zgodność z wymaganiami na oprogramowanie, a także ze specyfikacją, generalnymi założeniami,
standardami, procedurami, instrukcjami, kodami oraz kontraktowymi i licencyjnymi
wymaganiami.Aby zapewnić obiektywność, audyt powinien być przeprowadzony przez osoby
niezależne od zespołu projektowego.Audyt powinien być przeprowadzany przez odpowiednią
organizację audytu (która aktualnie formuje się w Polsce,
Polskie Stowarzyszenie Audytu) lub przez osoby posiadające uprawnienia/licencję audytorów.
Reguły i zasady audytu są określone w normie:
ANSI/IEEE Std 1028-1988 „IEEE Standard for Reviews and Audits”.
Celem Audytu jest dostarczenie odbiorcy i dostawcy obiektywnych, aktualnych i syntetycznych
informacji o stanie projektu.Zebrane informacje służą jako podstawa do podejmowania strategicznych
decyzji w projekcie

Przedmioty:
- procesy projektu informatycznego - ma to na celu sprawdzenie, czy wykonane prace oraz sposób ich
wykonania są prawidłowe
- produkty projektu informatycznego - ma to na celu sprawdzenie czy rezultaty poszczególnych prac
odpowiadają zakładanym wymaganiom.

Perspektywy:
- technologia - ma na celu sprawdzenie, czy uzyte techniki oraz opracowane rozwiazania sa
prawidlowe i prawidlowo stosowane
-zarzadzanie - ma to na celu sprawdzenie, czy sposób zarządzania projektem umożliwia jego sukces

35. Omów zagadnienie inspekcji oprogramowania w procesie wytwórczym systemów
informatycznych.

Inspekcja to formalna technika oceny, w której wymagania na oprogramowanie, projekt lub kod są
szczegółowo badane przez osobę lub grupę osób nie będących autorami, w celu identyfikacji błędów,
naruszenia standardów i innych problemów [IEEE Std. 729-1983]

- Inspekcje stosowane są dla "elitarnych" systemów, czyli takich, które spełniać mają bardzo ważne
zadania.
- nie jest prosta analiza kosztów inspekcji,
- nie ma gotowych narzędzi programowych - wymagane jest doświadczenie ludzi.

Korzyści z inspekcji:

- wzrost produktywności
- skrócenie czasu projektu
- zmniejszenie kosztu i skrócenie czasu wykonania testów (mniej testów regresyjnych)
- 10x mniejsze koszty pielęgnacji
- poprawa procesu programowego
- większy komfort pracy
- mniejsze koszty marketingu

Inspekcje przeprowadzane są przez specjalistów dla specjalistów bez udziału kierownictwa.
Przykładowo inspekcje modułów są przeprowadzane przez pracujące równolegle podgrupy
projektowe.

36. Omów rodzaje testów oprogramowania w odniesieniu do cyklu życia systemu
informatycznego.

- badanie prognostyczne - zanim powstanie kod źródłowy, czyli w fazach: określenia wymagań i
projektowania
Zalety:
Zwiększenie prawdopodobieństwa uniknięcia lub zmniejszenia oddziaływania zjawiska propagacji
błędów,
Stosunkowo niskie koszty testowania,
Możliwość przebadania wielu różnych projektów oprogramowania w celu wyboru najlepszego do
implementacji

Wady:
Bazowanie na modelu oprogramowania, co może zmniejszyc dokładność badania (potencjalna
rozbieżność z właściwościami implemetacyjnymi

−

badania diagnostyczne:

Typy:
- Analiza dynamiczna
- analiza statyczna
- inspekcje

−

audyty

−

37. Omów uwarunkowania prawne i inżynierskie procesu testów akceptacyjnych systemu
informatycznego.

Na podstawie art. 21 ust. 6 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów
realizujących zadania publiczne (Dz. U. Nr 64, poz. 565)
zarządza się, co następuje:

§ 1. Rozporządzenie określa:
1) metodykę , warunki i tryb sporządzania testów akceptacyjnych;
2) sposób postępowania w zakresie badania, o którym mowa w art. 21 ust. 1 ustawy z dnia 17 lutego
2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne, zwanego dalej
„badaniem”, w tym sposób dokumentowania wyników badania oraz weryfikacji badania;

§ 3. 1. Podmiot publiczny sporządza testy akceptacyjne z zachowaniem metodyki prowadzenia
projektów informatycznych o publicznym zastosowaniu odpowiadającej specyfice systemu
teleinformatycznego używanego do realizacji zadań publicznych, w zakresie obejmującym wyłącznie
funkcjonalność oprogramowania testowanego.
2. Sporządzenie testu akceptacyjnego obejmuje przygotowanie:
1) specyfikacji przypadku testowego, zgodnie z wzorem określonym w załączniku nr 1 do
rozporządzenia;
2) specyfikacji scenariusza testowego, zgodnie z wzorem określonym w załączniku nr 2 do
rozporządzenia, jeżeli jej sporządzenie jest niezbędne do przeprowadzenia badania z uwagi na
funkcjonalność oprogramowania testowanego.

§ 4. 1. Podmiot publiczny, mając na uwadze, aby badanie obejmowało w pełni funkcjonalność
oprogramowania testowanego:
1) sporządza opis badania składający się z:
a) specyfikacji poszczególnych przypadków testowych,
b) specyfikacji poszczególnych scenariuszy testowych w przypadku, o którym mowa w § 3 ust. 2 pkt 2;

2) zapewnia, nieodpłatnie dla podmiotów uprawnionych, dostęp do oprogramowania testowego albo,
zgodnie z § 5 ust. 2, do oprogramowania komunikacyjnego;
3) publikuje, w Biuletynie Informacji Publicznej, opis badania, o którym mowa w pkt 1, oraz
informacje
niezbędne dla uzyskania skutecznego dostępu przez podmioty uprawnione do oprogramowania, o
którym mowa w pkt 2.

38. Omów istotę testowania metodą black box i white box.

White box
Testowanie n/z białej skrzynki pozwala sprawdzić wewnętrzną logikę programów poprzez odpowiedni
dobór danych wejściowych, dzięki czemu można prześledzić wszystkie ścieżki przebiegu sterowania
programu. Tradycyjnie programiści wstawiają kod diagnostyczny do programu aby śledzić wewnętrzne
przetwarzanie. Debuggery pozwalają programistom obserwować wykonanie programu krok po kroku.
Często niezbędne staje się wcześniejsze przygotowanie danych testowych lub specjalnych programów
usprawniających testowanie (np. programu wywołującego testowaną procedurę z różnymi
parametrami).
Dane testowe powinny być dobrane w taki sposób, aby każda ścieżka w programie była co najmniej
raz przetestowana.
Ograniczeniem testowania na zasadzie białej skrzynki jest niemożliwość pokazania brakujących
funkcji w programie. Wadę tę usuwa testowanie n/z czarnej skrzynki.
Black box Tak określa się sprawdzanie funkcji oprogramowania bez zaglądania do środka programu.
Testujący traktuje sprawdzany moduł jak „czarną skrzynkę”, której wnętrze jest niewidoczne.
Testowanie n/z czarnej skrzynki powinno obejmować cały zakres danych wejściowych. Testujący
powinni podzielić dane wejściowe w „klasy równoważności”, co do których istnieje duże
przypuszczenie, że będą produkować te same błędy. Np. jeżeli testujemy wartość „Malinowski”, to
prawdopodobnie w tej samej klasie równoważności jest wartość „Kowalski”. Celem jest uniknięcie
efektu „eksplozji danych testowych”.
„Klasy równoważności” mogą być również zależne od wyników zwracanych przez testowane funkcje.

Np. jeżeli wejściem jest wiek pracownika i istnieje funkcja zwracająca wartości „młodociany”,
„normalny” „wiek emerytalny”, wówczas implikuje to odpowiednie klasy równoważności dla danych
wejściowych. Wiele wejść dla danych (wiele parametrów funkcji) może wymagać zastosowania
pewnych systematycznych metod określania ich kombinacji, np. tablic decyzyjnych lub grafów
przyczyna-skutek.

39. Omów zagadnienie architektury systemów informatycznych.

- Architektura globalna: koordynacja i komunikacja pomiędzy organizacjami;
- Architektura korporacyjna (enterprise): koordynacja i komunikacja w obrębie organizacji;
- Architektura systemu: koordynacja i komunikacja pomiędzy aplikacjami;
- Architektura aplikacji (Subsystem): dostarczanie funkcjonalności;
- Makro-architektura (Frameworks): powtarzające się aplikacje;
- Mikro-architektura: wzorce projektowe;
- Obiekty: specyficzne konstrukcje w językach programowania;

40. Omów zagadnienie projektowania architektonicznego systemów informatycznych.
Wzorce architektoniczne
1.Konstrukcyjne:
- Służą do pozyskiwania obiektów;
- Opisują szczegółowo, jak obiekt może zostać stworzony,
- Czynią kod niezależnym od typów tworzonych obiektów;
- Wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych;
- Przykłady:
+ Singleton,
+ Fabryka,
+ Metoda Fabrykująca,
+ Fabryka Abstrakcyjna,
+ Budowniczy,
+ Prototyp;
2.Strukturalne:
- Stosowany do łączenia obiektów w większe struktury;
- Zastosowanie np. w implementacji złożonego interfejsu użytkownika;
- Przykłady:
+ Fasada,
+ Adapter,
+ Most,
+ Kompozyt,
+ Dekorator,
+ Waga Piórkowa,
+ Proxy;
3.Operacyjne:
- W celu definiowania komunikacji pomiędzy obiektami;
- Pomagają kontrolować przepływ danych w złożonym programie;
- Przykłady:
+ Iterator,
+ Łańcuch Odpowiedzialności,
+ Stan,
+ Mediator,
+ Obserwator,
+ Strategia;

41. Omów istotę koncepcji wzorców projektowych w projektowaniu systemów informatycznych.

Wzorce projektowe stanowią powtarzalne rozwiązanie zagadnień projektowych, z którymi się wciąż
spotykamy;
- Wzorce dostarczają sprawdzonych rozwiązań dla powtarzających się problemów;
- Możliwe do zastosowania w wielu rzeczywistych kontekstach;
- Wpływają na sposób modelowania;
- Zapobiegają „wymyślaniu koła od nowa”;
- Usprawniają komunikację
- Ułatwiają tworzenie dokumentacji

42. Omów wzorzec projektowy …… (nazwa jednego z wzorców z wykładu).
- konstrukcyjne
--- służą do pozyskiwania obiektów;
--- opisują szczegółowo, jak obiekt może zostać stworzony,
--- czynią kod niezależnym od typów tworzonych obiektów;
--- wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych;
- strukturalne
--- stosowany do łączenia obiektów w większe struktury;
--- zastosowanie np. w implementacji złożonego interfejsu użytkownika
- operacyjne (czynnościowe)
--- definiowanie komunikacji pomiędzy obiektami;
--- kontrolowanie przepływów danych w złożonych algorytmach (programach);
--- przydział zobowiązań obiektom;

43. Omów model niezawodności oprogramowania według Jelińskiego-Morandy (1972).

- Wykrywanie błędów jest niezależne;
- Usuwanie wykrytych błędów nie generuje nowych;
- Intensywność wykrywania błędów - proporcjonalna do liczby błędów pozostających w
oprogramowaniu: (nie dałem rady przenieść tego wzoru)

44. Omów zjawisko propagacji kosztów błędu oprogramowania i podaj przykładowe szacunki
kosztów.

Wyniki badań przeprowadzonych przez Boehma w latach osiemdziesiątych jak i obecnie prowadzone
badania potwierdzają, że koszt poprawy błędu rośnie wykładniczo w zależności od etapu wytwarzania
oprogramowania. Najmniej kosztuje poprawa na etapie analizy, najwięcej po wdrożeniu systemu do
produkcji. Jeśliby błąd związany z rokiem 2000 usunąć na etapie implementacji to koszt z tym
związany byłby tysiąckrotnie niższy w stosunku do kosztu związanego z jego poprawą po wdrożeniu
systemu. W większości procesów wytwarzania testowanie systemu jest wykonywane na samym końcu.

Oznacza to, że jest ono szczególnie narażone na przekroczenie kosztów i harmonogramu, co oznacza
po prostu, że czas potrzebny na testowanie jest obcinany, ponieważ wcześniejsze fazy przekroczyły
termin i budżet.

Szacunki kosztów wg Roger’a Pressman’a (1997):
--- Testowanie: ~ 30 % - 40 % całkowitej pracochłonności;
--- Testowanie systemów krytycznych: 70% - 80% całkowitej pracochłonności (!);

45. Omów źródła kosztów nieprawidłowości oprogramowania.

Oprogramowanie zawierające błędy, może być źróbłem kosztów. Koszt wykrycia i naprawienia błędu
często przekrocza koszt napisania fragmentu kodu od nowa. Do kosztów oprogramowania złej jakości
zaliczamy:
1) Koszty jakości w skład których wchodzą:
-koszty błędów (traktowane jako straty),
-koszty oceny (traktowane jako nakłady),
-koszty zapobiegania (traktowane jako nakłady).
2) Koszty procesu:
-koszty niezgodności (traktowane jako straty),
-koszty zgodności (traktowane jako nakłady).
3) Straty jakości (skutki odchyleń od wymagań jakościowych)
Program złej jakości może mieć również potencjalnie duże koszty błędnych wykonań co może narazić
na wysokie straty finansowe instytucji korzystającej z błędnie działającego oprogramowania.
Oprogramowanie dobrej jakości to mniejsze koszty pielęgnacji (naprawczej) oraz mniejsze koszty
marketingu który ma na celu ukrywanie braku jakości

46. Co to jest testowanie, weryfikacja i walidacja oprogramowania? Podaj przykłady.

Testowanie oprogramowania proces związany z wytwarzaniem oprogramowania. Jest jednym z
procesów kontroli jakości oprogramowania. Testowanie oprogramowania jest jednym z kluczowych
etapów procesu zapewnienia jego jakości. Celem testowania oprogramowania jest sprawdzanie jak
dobry jest docelowy produkt oraz sprawdzenie czy oprogramowanie spełni swoje zadanie. Wsód
testów wyróżniamy testy dynamiczne, które polegają na wykonywaniu (fragmentów) programu albo
modeli symulacyjnych i porównywaniu uzyskanych wyników z wynikami poprawnym oraz testy
statyczne, oparte na analizie kodu albo modeli analitycznych lub projektowych .Testowaniu
oprogramowania podlega:Wydajność systemu, interfejsy systemu, własności operacyjne systemu, testy
zużycia zasobów oraz zabezpieczenie systemu

Weryfikacja - testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia
wymagań. Proces weryfikacji oprogramowania można określić jako poszukiwanie i usuwanie błędów
na podstawie obserwacji błędnych wykonań oraz innych testów. Weryfikacja uwzględnia następujące
czynności: przeglądy techniczne oraz inspekcje oprogramowania; sprawdzanie czy wymagania na
oprogramowanie są zgodne z wymaganiami użytkownika; sprawdzanie czy komponenty projektu są
zgodne z wymaganiami na oprogramowanie; testowanie jednostek oprogramowania (modułów);
testowanie integracji oprogramowania, testowanie systemu; testowanie akceptacji systemu przez
użytkowników

Walidacja (atestowanie)- ocena systemu lub komponentu podczas lub na końcu procesu jego rozwoju
na zgodności z wyspecyfikowanymi wymaganiami. Atestowanie jest więc weryfikacją końcową.
Walidacja sprawdza, czy oprogramowanie jest zgodne z oczekiwaniami użytkownika.

47. Omów istotę i przykłady metod prognostycznego badania jakości oprogramowania.

Badanie prognostyczne przeprowadzane są wtedy gdy nie ma kodu źródłowego.
Głównymi zaletami podejścia prognostycznego jest: Zwiększenie prawdopodobieństwa uniknięcia lub
zmniejszenia oddziaływania zjawiska propagacji błędów; stosunkowo niskie koszty testowania oraz
możliwość przebadania wielu różnych projektów oprogramowania w celu wyboru najlepszego do
implementacji. Wadą podejścia prognostycznego jest bazowanie na modelu oprogramowania, co może
zmniejszyc dokładność badania (potencjalna rozbieżność z właściwościami implemetacyjnymi).
Metody prognostyczne bazują na: metodach specyfikacji formalnej programów; badaniu logiki
sterowania programów oraz na metrykach projektu oprogramowania. Wyróżniamy dwa
komplementarne podejścia: badanie właściwości statycznych oraz badanie właściwości dynamicznych

48. Omów istotę i przykłady metod diagnostycznego badania jakości oprogramowania.

Badanie diagnostyczne przeprowadzane są gdy istnieje kod źródłowy. W skład diagnostycznego
badania oprogramowania wchodzi analiza dynamiczna czyli eksperymentowanie z działającym kodem
programu oraz analiza statyczna czyli praca z kodem źródłowym w celu rozpoznania funkcjonalności
testowanego kodu oraz zaprojektowania odpowiednich testów. Do Testów diagnostycznych zalicza się
testy strukturalne (testy białej skrzynki), które opracowuje się na podstawie wiedzy i implementacji
oprogramowania. Stosuje się je do stosunkowo niewielkich jednostek programów, takich jak
podprogramy i operacje związane z obiektem. Podczas testów strukturalnych tester może analizować
kod i korzystać z wiedzy o strukturze komponentu przy opracowywaniu danych testowych. Drugim
rodzajem testów diagnostycznych jest Testowanie strategią czarnej skrzynki. Polega ono na
sprawdzaniu funkcji oprogramowania bez zaglądania do środka programu. Testujący traktuje
sprawdzany moduł jak „czarną skrzynkę”, której wnętrze jest niewidoczne. Testowanie metodą czarnej
skrzynki powinno obejmować cały zakres danych wejściowych. Tester zadaje dane wejściowe i
analizuje dane wyjściowe. Jeżeli dane wyjściowe (wyniki) nie są zgodne z założeniami, to test
pozytywnie wykrył defekt oprogramowania.

49. Wymień i omów składowe jakości oprogramowania na drugim poziomie drzewa jakości.

Użyteczność - dostępność oczekiwanych usług
Niezawodność – np. prawdopodobieństwo błędu w czasie realizacji transakcji, średni czas pomiędzy
błędnymi wykonaniami, dostępność (procent czasu, w którym system jest dostępny), czas restartu po
awarii systemu, prawdopodobieństwo zniszczenia danych w przypadku awarii.
Wielokrotne użycie – ponowne wykorzystanie gotowych elementów
Pielęgnacyjność – podatność na pielęgnowanie, łatwość wprowadzania zmian
Przenośność – np. procent kodu zależnego od platformy docelowej, liczba platform docelowych, koszt
przeniesienia na nową platformę.
Testowalność – podatność na testowanie

50. Omów główne klasy błędów w systemach informatycznych

Klasyfikacja błędów:
- funkcjonalne - funkcja źle wykonana bądź źle funkcjonująca
- systemowe - nieprawidłowe zarządzanie zasobami, mylne interfejsy, zła komunikacja z bazą danych
bądź jej brak
- przetwarzania - niewłaściwe przetwarzanie danych w poszczególnych modułach
- danych - źle wprowadzone dane, ich brak, błędna specyfikacja
- graficzne - interfejs graficzny niezgodny z założeniami
- kodowania - niewłaściwe użycie języka programowania
- dokumentacji - niepełna lub błędna dokumentacja
- inne - niezidentyfikowana przyczyna wystąpienia

51. Omów czynności procesu testowania oprogramowania.

Fazy procesu testowania:
- testowanie komponentów (jednostek) - testuje się poszczególne komponenty, aby zapewnić, że
działają poprawnie,
- testowanie modułów - moduł jest kolekcją niezależnych komponentów takich jak klasy obiektów,
abstrakcyjne typy danych, albo bardziej luźną kolekcją procedur i funkcji,
- testowanie podsystemów - ta faza obejmuje testowanie kolekcji modułów, które zintegrowano w
podsystemie,
- testowanie systemu - ten proces testowania ma wykryć błędy wynikające z nieprzewidzianych
interakcji między zintegrowanymi podsystemami i problemów z interfejsami podsystemów,
- testowanie odbiorcze - jest to końcowa faza procesu testowania przed przyjęciem systemu do
użytkowania.

52. Co to jest przypadek testowy, scenariusz testów? Podaj przykłady.

Scenariusz testów:
- dokument opisujący procedury i przypadki testowe dla określonego produktu
- jest podstawą pracy testera z danym produktem
- obejmuje:
--- listę testowanych produktów
--- odwołania do wymagań
--- przypadki testowe
--- kryteria poprawności
--- listę agentów testowych
--- szczegółowe procedury testowania dla produktów

Przypadek testowy:
- ściśle określona ścieżka przejścia przez testowany produkt lub charakterystyczna klasa danych
wejściowych
- określa szczegółowy zakres w testowanym produkcie, pozwalający rozłożyć skomplikowany problem
testowy na elementarne części

53. Co to jest macierz przykrycia testów akceptacyjnych? Podaj przykłady.

Testy akceptacyjne:
– Pozwalają sprawdzić, na ile oprogramowanie działa zgodnie z wymaganiami klienta;
– Leżą w gestii klienta lub użytkownika systemu oraz również współudziałowcy;
– Szukanie defektów nie jest głównym celem tego testowania;
– Dzielą się na testy:
» użytkownika - weryfikuje dopasowanie systemu do potrzeb użytkowników;
» operacyjne - akceptacja systemu przez administratorów systemu zawierające: sprawdzenie kopii
zapasowej i zdolności do przywrócenia funkcjonalności po wystąpieniu problemów, zarządzanie
użytkownikami, zadania serwisowe, cykliczne sprawdzenie bezpieczeństwa;
» kontraktowe i regulacyjne - testowanie kryteriów wytworzenia oprogramowania specyfikowanego
dla klienta (np. są wykonywane w zgodzie z rządowymi lub legislacyjnymi uregulowaniami);
» alfa / beta – dla systemów: na zamówienie / „z półki”;

54. Omów podstawowe schematy testów integracyjnych. Podaj przykłady.

-Skokowe - grupują wybrane (lub wszystkie) jednostki w celu ich równoczesnego przetestowania
-Przyrostowe - zakładają dołączenie do tworzonej całości za każdym razem tylko jednej uprzednio
przetestowanej jednostki:
– zstępujące (odgórne) - integruje się i testuje się komponenty wysokiego poziomu przed ukończeniem
ich projektu i implementacji; np.: (Namiastka (stub):
- imituje jednostki niższego poziomu
- zastępuje moduły wywoływane przez
testowany moduł )
– wstępujące (oddolne) - testuje się i integruje komponenty niskiego poziomu przed ukończeniem
budowy komponentów wyższego poziomu;np.:( Sterownik (driver):
- dostarcza jednostkom niższego poziomu dane
- zastępuje moduł wywołujący testowane moduły)

55. Jaka jest istota konstrukcyjnych wzorców projektowych? Przedstaw przykład wzorca
konstrukcyjnego.

-Służą do pozyskiwania obiektów;
-Opisują szczegółowo, jak obiekt może zostać stworzony,
-Czynią kod niezależnym od typów tworzonych obiektów;
-Wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych;
-Przykłady:
-Singleton,
-Fabryka,
-Metoda Fabrykująca,
-Fabryka Abstrakcyjna,
-Budowniczy,
-Prototyp;

56. Jaka jest istota strukturalnych wzorców projektowych? Przedstaw przykład wzorca
strukturalnego.