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

1

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.

2

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.

3

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.

4

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

5

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

6

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.

7

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.

8

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

9

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ę

10

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.

11

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.

12

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

13

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

14

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

15

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ę

16

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.

17

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;

18

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

19

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ą.

20

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.

21

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.

22

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.

23

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)

24

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.

25

26. Omów główne cechy modelu analitycznego i podstawowe czynności w fazie analizy
systemu informatycznego.

Cechy modelu analitycznego (logicznego):
-Uproszczony opis systemu;
-Hierarchiczna dekompozycja funkcji systemu;
-Model logiczny jest opisany przy pomocy notacji zgodnej z pewną konwencją;
-Jest on zbudowany przy użyciu dobrze rozpoznanych metod i narzędzi;
-Jest on używany do wnioskowania o przyszłym oprogramowaniu;
-Model oprogramowania powinien być jego uproszonym opisem, opisującym wszystkie
istotne cechy oprogramowania na wysokim poziomie abstrakcji.
-Model ten jednakże nie zastępuje doświadczenia i wnikliwości projektantów, lecz pomaga
projektantom w zastosowaniu tych walorów.

Logiczny model oprogramowania:
• pokazuje co system musi robić;
• jest zorganizowany hierarchicznie, wg poziomów abstrakcji
• unika terminologii implementacyjnej
• pozwala na wnioskowanie „od przyczyny do skutku” i odwrotnie.

Czynności w fazie analizy:
-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.

26

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;

27

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;

28

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

29

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.

30

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 ( : ).

31

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.

32

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.

33

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

34

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.

35

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

36

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.

37

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.

38

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;

39

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;

40

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

41

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;

42

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)

43

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 (!);
Dodatkowo należy brać pod uwagę tzw. koszty utraconych korzyści

44

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

45

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.

46

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

47

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.

48

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

49

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

50

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.

51

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

52

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”;

53

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)

54

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;

55

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

Strukturalne wzorce projektowe
- Zastosowanie np. w implementacji złożonego interfejsu użytkownika;
- Stosowane do łączenia obiektów w większe struktury
Jednym z przykładów jest Fasada:
- Ujednolicony i prostszy interfejs do struktury złożonych podsystemów;
- Separacja klienta od złożonych podsystemów;
- Wybór odpowiedniej struktury dla żądania klienta;
- Możliwości zmian w ukrywanych podsystemach;
Np.
- w bibliotekach Javy: klasy pakietu java.sql (Statement, ResultSet);
- wejście usług w Service Oriented Architecture (SOA);

56

57. Jaka jest istota czynnościowych wzorców projektowych? Przedstaw przykład wzorca
czynnościowego.

Wzorce czynnościowe inaczej zwane operacyjnymi, służą do:
- definiowanie komunikacji pomiędzy obiektami;
- kontrolowanie przepływów danych w złożonych algorytmach (programach);
- przydział zobowiązań obiektom;
Jednym z przykładów może być iterator:
- Upraszcza przemieszczanie po kolekcji danych (np. liście), z wykorzystaniem
standardowego interfejsu;
- Nie wymaga znajomości wewnętrznej struktury kolekcji danych;
- Umożliwia równoczesne przeglądanie kilku kolekcji;
Np.
- W bibliotekach Javy: iterator w kolekcjach z pakietu java.util;

57