1.

Omów przedmiot i zakres inżynierii oprogramowania.

Przedmiot:

Inżynieria oprogramowania jest wiedzą techniczną dotycząca wszystkich faz cyklu życia 
oprogramowania. Traktuje oprogramowanie jako produkt, który ma spełniać potrzeby 

techniczne, ekonomiczne lub społeczne.  
Dobre oprogramowanie powinno być:

- zgodne z wymaganiami użytkownika,
- niezawodne,

- efektywne,
- łatwe w konserwacji,

- interoperacyjne (jeżeli nie jest autonomiczne)
- ergonomiczne.

Inżynieria oprogramowania jest wiedzą empiryczną, syntezą doświadczenia tysięcy ośrodków 
zajmujących się budową oprogramowania. 

Zakres:

Sposoby prowadzenia przedsięwzięć informatycznych.
Techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć 

informatycznych.
Metody analizy i projektowania systemów.

Techniki zwiększania niezawodności oprogramowania.
Sposoby testowania systemów i szacowania niezawodności.

Sposoby przygotowania dokumentacji technicznej i użytkowej.
Procedury kontroli jakości.

Metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń)
Techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.

2.

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

Język programowania jest środkiem umożliwiającym zapis algorytmów w postaci zrozumiałej 

dla człowieka, a równocześnie przetwarzanej do postaci zrozumiałej dla komputera (maszyny 
algorytmicznej)

Semiotyka zajmuje się badaniem symboli, znaków. W jej skład wchodzą:
syntaktyka, zajmująca się określaniem przynależności danego słowa do zestawu słownika 

określonego języka programowania
semantyka, zajmująca się określeniem znaczenia programu, zapisanego w określonym języku 

programowania

Syntaktyka jest częścią ogólnej teorii znaków (semiotyki) i zajmuje się strukturą i formą 
wyrażeń, a także dopuszczalnymi zmianami ich formy, zwanymi „przekształceniami”.

Wyróżnia się dwa rodzaje reguł składniowych:
reguły formowania, określające zbiór wyrażeń poprawnie zbudowanych na określonym 

alfabecie języka
reguły przekształcania, określające zbiór możliwych przekształceń na bazie słów z zadanego 

zestawu słownika

W dziedzinie algorytmiki, jak również logiki matematycznej mają zastosowanie wyłącznie 
reguły inferencyjne, tzn. takie przekształcenia, które są prawdziwe w sensie logiki

Najczęściej przyjmuje się, że mamy do czynienia z dwoma podzbiorami dziedziny nazywanej 

syntaktyką:
syntaktyka formalna, która jest rozumiana jako ogólne badania formalne, dotyczące języków 

logiki i matematyki, jak również języków naturalnych,
syntaktyka logiczna, która zajmuje się badaniem języków logiki i matematyki (np. rachunek 

predykatów, rachunek zdań)

Językami programowania, badaniem ich algorytmiczności zajmuje się syntaktyka języków 
programowania, która jest jednym z rodzajów syntaktyk formalnych

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

Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i 

procesów ich wytwarzania

Skutki:
27% projektów powstaje w założonym czasie, budżecie i funkcjonalności

33% projektów przekracza czas, budżet i ma mniejszą funkcjonalność
40% projektów jest przerywanych

53% projektów przekracza koszty o 51%
68% projektów przekracza czas o 51% 

69% niepowodzeń to czynniki pozainformatyczne.

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

Dziedzina problemowa, 

obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów.
Środki i technologie informatyczne: 

sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia.
Zespół projektantów: podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i 

komunikacji.
Potencjalni użytkownicy: 

czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do  błędów i 
nadużyć, tajność, prywatność. 

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

Zasada dekompozycji: 

rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać 
niezależnie od siebie i niezależnie od całości.  

Zasada abstrakcji: 

eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub 
mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru 

bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy.

Zasada ponownego użycia: 
wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, 

komponentów oprogramowania, itd.

Zasada sprzyjania naturalnym ludzkim własnościom:
dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich 

własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia 
świata. 

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

Projektant i programista muszą dokładnie wyobrazić sobie problem  oraz metodę modelowania 

pojęciowego. Zasadnicze procesy tworzenia  oprogramowania zachodzą w ludzkim umyśle i nie 
są związane z  jakimkolwiek językiem programowania. 

Pojęcia modelowania pojęciowego  (conceptual modeling ) oraz modelu pojęciowego 

(conceptual model ) odnoszą się procesów  myślowych i wyobrażeń towarzyszących pracy nad 
oprogramowaniem. 

Modelowanie pojęciowe jest wspomagane przez środki  wzmacniające ludzką pamięć i 

wyobraźnię. Służą one do  przedstawienia rzeczywistości opisywanej przez dane, procesów 
zachodzących w rzeczywistości, struktur danych oraz programów  składających się na 

konstrukcję systemu. 

Perspektywy w modelowaniu pojęciowym:
Percepcja rzeczywistego świata <-- odwzorowanie --> Analityczny model rzeczywistości <-- 

odwzorowanie --> Model struktur danych i procesów SI   

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. 

Metodyka jest powiązana z notacją służącą do dokumentowania wyników faz projektu 
(pośrednich, końcowych), jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek 

komunikacji w zespołach oraz pomiędzy projektantami i klientem.

Metodyka ustala:

- fazy projektu, role uczestników projektu,
-  modele tworzone w każdej z faz,

 

- scenariusze postępowania w każdej z faz, 
-  reguły przechodzenia od fazy do następnej fazy, 

 

- notacje, których należy używać,

 

- dokumentację powstającą w każdej z faz.

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

1. Model kaskadowy:

Model kaskadowy zwany tez modelem wodospadu lub liniowym, jest klasycznym 

modelem cyklu życia oprogramowania. Jest to model, który został zaproponowany poprzez 

analogię do sposobu prowadzenia przedsięwzięć w innych dziedzinach inżynierii, na przykład 
budownictwie.

Model kaskadowy składa się czynności które podczas tworzenia oprogramowania 

są  wykonywane sekwencyjnie:

-określenie wymagań , w której określane są cele oraz szczegółowe wymagania wobec 
tworzonego systemu.

-analiza 
-projektowanie, w której powstaje szczegółowy projekt systemu spełniającego ustalone 

wcześniej wymagania.
-implementacja, w której projekt zostaje zaimplementowany w konkretnym środowisku 

programistycznym oraz wykonane są testy poszczególnych modułów.
-testowanie, w której następuje integracja poszczególnych modułów połączonych z 

testowaniem poszczególnych podsystemów oraz całego oprogramowania.
-konserwacja, w której oprogramowanie jest wykorzystywane przez użytkowników,

a producent dokonuje konserwacji oprogramowania – wykonuje modyfikacje polegające 
na usuwaniu błędów, zmianach i rozszerzaniu funkcji systemu.

Wady modelu kaskadowego:

- 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

Model ten mimo swoich wad jest niezbędny dla planowania, harmonogramowania, 

monitorowania i rozliczeń finansowych.
Występuje także zmodyfikowany model kaskadowy z iteracjami. Modyfikacja ta polega na tym, 

że z każdej fazy można się cofnąć do faz wcześniejszych.

2. Model spiralny, przyrostowy, ewolucyjny

Model spiralny składa się z czterech głównych faz wykonywanych cyklicznie:

- analiza ryzyka

- konstrukcji
- atestowania

- planowania

W pierwszej fazie rozważane są ogólne opcje budowy nowej wersji systemu. Możliwości 

te są analizowane przy wzięciu pod uwagę ryzyka związanego z ich realizacją. Problematyka 

analizy opcji omawiana jest w kolejnym rozdziale dotyczącym fazy strategicznej realizacji 
przedsięwzięcia. Faza ta może obejmować także budowę prototypu.

W kolejnej fazie konstruowana jest kolejna wersja systemu w sposób zgodny z modelem 

kaskadowym.

W fazie atestowania kolejna wersja systemu jest oceniana przez klienta.  Jeżeli ocena nie 

jest w pełni pozytywna rozpoczynany jest kolejny cykl.

W fazie planowania ustalane są generalne cele produkcji kolejnej wersji systemu.

Model przyrostowy:

Rozpoczyna się od określenia wymagań oraz wykonania wstępnego, ogólnego 

projektu całości systemu. Następnie wybierany jest pewien podzbiór funkcji systemu. Dalej, 

zgodnie z przebiegiem modelu kaskadowego, wykonywany jest szczegółowy projekt oraz 
implementacja części systemu realizującej te funkcje. Po przetestowaniu zrealizowany 

fragment pełnego systemu może zostać dostarczony klientowi.

Zalety tego modelu to:

- skrócenie przerw w kontaktach z klientem.
- możliwość wczesnego wykorzystania przez klienta dostarczonych fragmentów 

systemu.

- możliwość elastycznego reagowania na powstałe opóźnienia. Jeżeli realizacja 

fragmentu systemu opóźni się, nie musi to oznaczać opóźnienia całego przedsięwzięcia. Istnieje 
wtedy możliwość przyspieszenia prac nad dalszymi częściami.

Wadą tego modelu jest pewien dodatkowy koszt związany niezależną realizacją 

fragmentów systemu. Z reguły nie jest możliwe proste wycięcie podzbioru funkcji w pełni 

niezależnych od pozostałych. W związku z tym może zajść konieczność implementacji tzw. 
Szkieletów modułów, tj. modułów o interfejsie zgodnym z modułami, które znajdą się pełnym 

systemie lecz nie realizujących w pełni ich funkcji. Implementacja tych modułów to oczywiście 
pewien dodatkowy nakład pracy oraz zwiększone ryzyko nie wykrycia  błędów w fazie 

testowania.

Model ewolucyjny:

Wytwarzanie ewolucyjne polega na: 

- opracowaniu wstępnej implementacji, 

- pokazaniu jej użytkownikowi z prośbą o komentarze
- udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu;

Rodzaje wytwarzania ewolucyjnego:

Tworzenie badawcze:

- celem procesu jest praca z klientem, polegająca na badaniu wymagań i 

dostarczeniu ostatecznego systemu;

- tworzenie rozpoczyna się od tych części systemu, które są dobrze rozpoznane;
- system ewoluuje przez dodawanie nowych cech, które proponuje klient;

Prototypowanie z porzuceniem:

- celem procesu tworzenia ewolucyjnego jest zrozumienie wymagań klienta i 

wypracowanie lepszej definicji wymagań stawianych systemowi;

- budowanie prototypu ma głównie na celu eksperymentowanie z tymi 

wymaganiami użytkownika, które są niejasne;

Wady modelu ewolucyjnego:

-proces nie jest widoczny;
-system ma złą strukturę;

-konieczne mogą być specjalne narzędzia i techniki;

Stosowanie:

- w wypadku systemów małych (mniej niż 100 000 wierszy kodu) lub średnich (do 

500 000 wierszy kodu) z krótkim czasem życia podejście ewolucyjne jest dobre;

-  wypadku dużych systemów o długim czasie życia wady tworzenia ewolucyjnego 

ujawniają się jednak z całą ostrością;

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

Model ten składa się z następujących faz:

- ogólne określenie wymagań

 

- budowa prototypu

 

- weryfikacja prototypu przez klienta

 

- pełne określenie wymagań

 

- realizacja pełnego systemu zgodnie z modelem kaskadowym

Głównym celem realizacji prototypu jest lepsze określenie wymagań, czyli:

- wykrycie nieporozumień pomiędzy klientem a twórcami systemu

-  wykrycie brakujących funkcji
-  wykrycie trudnych usług

 

- wykrycie braków w specyfikacji wymagań

4. Programowanie odkrywcze:

Programowanie odkrywcze zalecane jest w sytuacjach gdy określenie wymagań klienta 

może być tak trudne, że nawet budowa pojedynczego prototypu nie wystarcza dla rozwiania 

wszelkich wątpliwości. Model ten rozpoczyna się od wstępnego, bardzo ogólnego określenia 
wymagań. Następnie bardzo szybko rozpoczyna jest realizacja systemu. Faza realizacji 

obejmuje z reguły wykonanie przynajmniej bardzo ogólnego projektu. System jest następnie 
weryfikowany przez klienta. Jeżeli zostanie on uznany za nieodpowiedni, budowana jest kolejna 

wersja systemu. Nie jest to przy tym budowa od podstaw lecz najczęściej modyfikacja 
poprzedniej wersji. Cykl kończy się jeżeli jedna z kolejnych wersji zadowala klienta, lub dojdzie 

on do wniosku, że nie jest możliwe osiągnięcie zadowalającego efektu.

Zaletą tego modelu jest możliwość stosowania nawet w wypadkach dużych trudności z 

określeniem wymagań klienta.

Wady tego modelu:

- praktycznie niemożliwe jest zachowanie sensownej struktury systemu, nawet 

jeżeli na wstępie wykonano ogólny projekt. Struktura zaproponowana na wstępie na pewno 

zaginie w kolejnych iteracjach wprowadzania zmian do systemu. Po kilku iteracjach okazuje się, 
że wprowadzanie kolejnych zmian i usuwanie kolejnych błędów, powoduje dodawanie nowych 

błędów. W efekcie praktycznie nie możliwe jest wykonanie w ten sposób większych systemów o 
zadowalającej niezawodności.

- ponieważ model ten nie obejmuje pełnego określenia wymagań, testowanie 

systemu może odbywać się prawie wyłącznie przy bezpośrednim udziale klienta. W wypadku 

innych modeli testowanie polega przede wszystkim na weryfikowaniu zgodności systemu z 
wcześniej sprecyzowanymi wymaganiami.

5. Model „V”;

Polega na wytwarzaniu równolegle oprogramowania i prowadzeniu testów akceptacji, 

poszczególne elementy systemu są badane od razu po wytworzeniu, praca polega na podziale 

systemu na podsystemy, a te na poszczególne zadania, co robi jeden z zespołów, a drugi 
zespół odpowiada wyłącznie za ocenę i testowanie systemu. testy odbywają sie od zadań, 

potem przechodzą do testowania podsystemów, a następnie testowany jest pełny system.

6. Montaż z gotowych elementów

Model montażu z gotowych elementów kładzie szczególny nacisk na możliwości redukcji 

nakładów przez maksymalne wykorzystanie podobieństw tworzonego oprogramowania do 

wcześniej tworzonych systemów.

Gotowe elementy mogą być wykorzystywane na różnych etapach realizacji 

przedsięwzięcia. Najczęściej są one wykorzystywane  na etapie implementacji. Przykładem 
może być stosowanie:

- bibliotek
- języków czwartej generacji, których złożone instrukcje mogą być traktowane 

jako odwołania do wybudowanych bibliotek

- pełnych aplikacji np. wykorzystanie przeglądarki plików pomocy w systemie MS 

Windows

Istnieją dwie metody pozyskiwania gotowych elementów:

- zakup od zewnętrznych dostawców
- opracowanie wyników aktualnie realizowanych przedsięwzięć tak, aby mogłyby 

być wykorzystane w kolejnych przedsięwzięciach.

Zalety stosowania gotowych elementów to:

- wysoka niezawodność
- zmniejszenia ryzyka

- efektywne wykorzystanie specjalistów
- narzucanie standardów

Wadami tego modelu są:

- dodatkowy koszt przygotowania elementów do ponownego wykorzystania.

- ryzyko uzależnienia się od dostawcy elementów
- niedostatki narzędzi wspomagających ten rodzaj pracy

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

Czynniki psychologiczne mają zasadniczy wpływ na efektywność pracy zespołu. 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  

Wymiar produktu:

•

Przez produkty projektu rozumie się wszystkie jego elementy, które mogą 

powstać w wyniku jego realizacji. 

•

Może to być  gotowe oprogramowanie, zainstalowane systemy, dokumentacja 

oprogramowania, różnego rodzaju procedury, wykształcone kadry ludzkie itp. 

•

Opracowanie planów działań w wymiarze produktów odbywa się na podstawie 

definicji zakresu projektu.

Wymiar czasu:

•

Na podstawie precyzyjnie zdefiniowanego zakresu projektu można 

zdefiniować drugi wymiar projektu, czyli czas, który jest najczęściej 

zapisywany w postaci harmonogramu. 

•

Często spotykaną formą prezentacji harmonogramu są na przykład tabele 

lub arkusze kalkulacyjne, jak również wykresy Gantta, które przedstawiają 

poszczególne czynności projektowe w sieci uwzględniającej wzajemne ich 
zależności, następstwa i zasoby niezbędne do ich wykonania w 

odpowiednio zdefiniowanej skali czasu.

Wymiar budżetu:

•

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

•

Koszt ten powinien być podzielony na poszczególne jego kategorie. 

•

Mogą to być:

♦

koszty osobowe, 

♦

koszty sprzętu, 

♦

administracji projektu, 

♦

delegacji, 

♦

szkoleń itp.

Wymiar jakości:

•

oceny zarówno poszczególnych produktów projektowych:



dokumentacji, 



oprogramowania, 



platformy techniczno-systemowej  itp.

•

jak i oceny organizacji procesu projektowego:



planu wzajemnych oddziaływań procesów projektowych, 



zasobów ludzkich zaangażowanych w projekt, 



zarządzania poszczególnymi wymiarami projektu itp.

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

Prince2.

W większych projektach powołuje się: menedżera konfiguracji , archiwum projektu, 

planiste

Dodatkowe informacje (jak chcesz 3 nie czytaj dalej)!!!

Szef projektu- jest personalnie odpowiedzialny za sukces lub porażkę projektu, decyduje na 

szczeblu operacyjnym. Szefowie ze strony użytkownika i ze strony dostawcy tworzą Zarząd 
Projektu.

Szef projektu u użytkownika- odpowiada za: współorganizację prac projektowych i 

zapewnienie zasobów dla projektu ze strony klienta
Szef projektu u dostawcy – odpowiada za: 1.organizowanie (planowanie) projektu i prac oraz 

korygowanie planów 2. ustalenie założeń, wymagań użytkownika oraz kryteriów akceptacji 
produktów projektowych 3. kontrolę postępów i ich raportowanie (produkt, czas, budżet) 4. 

mianowanie Szefów Zespołów i Sekretariatu Projektu 5. dostarczenie produktów do testów i 
akceptacji 6. zapewnienie zasobów ze strony dostawcy 7. zorganizowanie prac Komitetu 

Sterującego 8. kontakty z poddostawcami 
Sekretariat/administracja biura projektu – wykonuje zadania w zakresie

: 1. prowadzenia biblioteki projektu, planów, raportów, wniosków o zmianę itp.  2. zarządzania 
korespondencją, dokumentacją spotkań 3. zbierania i konsolidacji raportów z zespołów 

technicznych 4. przygotowania materiałów do raportów Szefa Projektu 5. spraw osobowych 
(urlopy, rozliczenia finansowe, sprawy pracownicze itp.) 6. rozliczeń finansowych z dostawcami 

zewnętrznymi 7. rozliczeń finansowych z klientem 

Zespoły Realizacyjne
  -są   wykonawcami   produktów   i   dlatego   od   ich   prawidłowego   składu   i   organizacji   zależy 

powodzenie realizacji projektu.

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

Zarządanie:

Zakresem – obejmuje procesy dające pewność że projekt uwzględnia wszystkie konieczne 
czynności niezbędne dla pomyślnego zakończenia projektu i uzyskania oczekiwanego zakresu 

produktu
.  

Główne procesy to: 1.inicjowanie faz projektu 2.planowanie zakresu 3.definiowanie zakresu 

4.weryfikacja zakresu 5.kontrola zmian zakresu

 

Kosztem-obejmuje procesy wymagane do zapewnienia, że projekt zostanie ukończony w 

ramach zaakceptowanego budżetu. 

Główne procesy to:

1.planowanie zasobów 2.estymowanie kosztu 3.przypisywanie kosztów (budżetowanie) 

4.kontrola kosztu 5.zarządzanie zmianami budżetu 

Harmonogramem(czasem)- obejmuje procesy wymagane do zapewnienia przestrzegania 

przez zespół projektowy ustalonych granic czasowych dla poszczególnych czynności w 
projekcie. 

Główne procesy to: 1.definiowanie czynności 2.sekwencjonowanie czynności 

3.estymowanie czasu 4.opracowanie harmonogramu  5.kontrola wykonania harmonogramu 
6.zarządzanie zmianami harmonogramu

Jakością-obejmuje procesy wymagane do zapewnienia zaspokojenia przez rezultaty projektu 
tych potrzeb, dla których został on powołany. 

Główne procesy to:1.planowanie jakości 

2.zapewnienie jakości 3.kontrola jakości 

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

Główne procesy: 1.planowanie komunikacji 

2.dystrybuowanie informacji 3.sprawozdawczość

Integracją-obejmuje   procesy   wymagane   do   zapewnienia   poprawnej   koordynacji   wszystkich 

elementów   projektu.  

Główne   procesy:1.wypracowanie   planu   projektu   2.wykonywanie   planu 

projektu 3.ogólna kontrola zmian projektu

 

Ryzykiem -obejmuje procesy identyfikacji, analizowania i reakcji na zaistnienie czynników 
ryzyka w projekcie. 

Główne procesy: 1.identyfikacja ryzyka 2.estymowanie ryzyka 

3.optymalizacja ryzyka 4.monitorowanie ryzyka

Zasobami ludzkimi- obejmuje procesy ułatwiające efektywne wykorzystanie ludzi w projekcie 

(klientów, sponsorów i innych uczestników).

Główne procesy:

1.planowanie   organizacji   2.nabór   personelu   3.zarządzanie   zespołami   ludzkimi 

Zaopatrywaniem/zleceniami/sprzedażą  obejmuje   zdobywanie   dóbr   i   usług   spoza 
organizacji   wykonującej   projekt  

Główne   procesy:1.planowanie   zleceń   2.planowanie   ofert 

3.realizacja ofert 4.selekcja dostawców 

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

metodyki Chestra SBS.

Informacje dodatkowe:

Kierownik Projektu(Szef projektu)– posiada  

-

silną pozycje

Architekt Systemowy i Biznesowy – określają zakres projektu i zakres produktu 
Techniczne zarządzanie projektem – wyróżniono dokumentacje użytkownika i obszary 

testów

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

 

(ps.co do Chestra SBS to jest on kurwa wielką niewiadomą co potwierdza slajd opisujący 
zawartość prezentacji który mówi o elementach Chestra v. 2.0 z Siemens Business Services 

natomiast pytanie wymaga znajomości zarządzania projektem informatycznym wg tej metodyki
, poniżej zamieszczam moje wypociny)

Studiując metodyką Prince2 można odnieść nieodparte wrażenie, że jest ona mocno 
sugerowana osiągnięciami standardów PMI. Wydaje się, że autorom metodyki Prince2 zależało 

przede wszystkim na pewnym zagregowaniu, usystematyzowaniu i przełożeniu zasad
określonych w standardach północno-amerykańskich na uwarunkowania rynku europejskiego.

Różnice w zakresie zarządzania projektem informatycznym w Prince2 i PMI

Różnice w organizacji biura projektu informatycznego w Prince2 i Chestr SBS:

W zaleceniach Prince 2  wyróżnia się szefa projektu od strony użytkownika i dostawcy (tworzą 
oni zarząd projektu), w Chestr  jest jeden szef projektu inaczej zwany kierownikiem, 

posiadający silną pozycje. Istotne różnice  w administracji projektu to: w Prince2 menedżer 
konfiguracji(powoływany do większych projektów) który to w  metodyce Chestr nie jest 

składową administracji projektu a dodatkowo w Chestr  powołuje się menedżerów budżetu i 
jakości. Kolejną różnicą jest w Chestr architekt systemowy i biznesowy(określają zakres projektu 

i produktu) natomiast w Prince2 sekretariat biura projektu. Wyróżnionymi obszarami w Chestr 
jest dokumentacja i testowanie. W metodyce Prince2 dzięki oddzieleniu grupy zarządczej, 

odpowiedzialnej za organizację i kierowanie, od technicznej wytwarzającej produkt, może ona 
znaleźć zastosowanie w wielu dziedzinach. 

Co do Chestra to ambitnych odsyłam do toolboxa 

Siemensa który dodaje jako załącznik.

Cechy:
W Prince2 skoncentrowano się na określeniu zasad organizacji i zarządzania projektem, co ma 

w przekonaniu jej autorów gwarantować prawidłowe jego rozpoczęcie i doprowadzenie do 
pomyślnego zakończenia oraz wypracowanie oczekiwanych produktów, przy jednoczesnym 

dotrzymaniu planowanego czasu, budżetu i jakości projektu. 

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

Zarządzania konfiguracją ma na celu: 1. identyfikacje i udokumentowanie funkcjonalnych 
oraz niefunkcjonalnych charakterystyk produktów projektowych 2. monitorowanie wszelkich 

zmian tych charakterystyk 3. zapisywanie i raportowanie zmian oraz stopnia implementacji 
zmian 4. weryfikacje poszczególnych produktów projektowych pod względem spełniania 

wymagań ustalonych dla tych produktów 

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

Celem fazy określenia wymagań jest ustalenie wymagań klienta wobec tworzonego systemu. 

Dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie 
tych celów. Proces inżynierii wymagań to: wynajdowanie, analizowanie, specyfikowanie i 

dokumentowanie sprawdzania usług i ograniczeń
 W zakresie inżynierii wymagań  wyróżnia się: wymagania użytkownika, wymagania 

systemowe, wymagania funkcjonalne i niefunkcjonalne, dokumentacje wymagań stawianych 
oprogramowaniu.

Punktem   wyjściowym   w   projektowaniu   w   pełni   funkcjonalnej   aplikacji   są   trzy   podstawowe 
elementy związane z inżynierią wymagań, czyli: 



zebranie wymagań użytkowników, 



zarządzanie   tymi   wymaganiami,   czyli   zestawienie   powstałej   specyfikacji   z 

oczekiwaniami klienta, 



weryfikowanie   tych   wymagań   poprzez   stałą   komunikację   całego   zespołu,   aby 
upewnić się, że powstaje odpowiednia aplikacja.

Projekt powinien odnosić się do trzech poziomów wymagań: 1.Wymagania biznesowe(potrzeby) 
2. Wymagania użytkownika(cechy) 3.Wymagania systemowe(funkcjonalne, niefunkcjonalne)

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

Dobry opis wymagań powinien być:

-Kompletny
-Niesprzeczny

-Weryfikowalny
-Realizowalny

Ponadto:
–Opisywać zewnętrzne zachowania systemu z pominięciem sposobu jego realizacji

–Obejmować ograniczenia, przy jakich musi pracować system
–Łatwy w modyfikacji

–Zapewniać możliwości zmiany wymagań w kolejnych etapach
–Zawierać zachowania systemu w niepożądanych lub skrajnych sytuacjach (brzegowych)

Metody rozpoznawania 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.

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

       takich wymagań.
Główne klasy wymagań to Funkcjonalne, Niefunkcjonalne i Dziedzinowe

    Funkcjonalne (jakie usługi oferuje, jak ma reagować, jakie dane przyjmować) :
-system wymaga logowania użytkownika

-możliwość sprawdzania postępów pracy w każdym momencie 
    Niefunkcjonalne( ograniczenia czasowe, standardy) :

-system powinien odszukiwać dane każdego użytkownika poniżej 10 sekund
-system nie powinien zajmować więcej niż 10GB

    Dziedzinowe (odzwierciedlają charakterystykę dziedziny systemu, mogą być  
    funkcjonalne lub niefunkcjonalne): 

-Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika,  
  którego podstawą jest standard Z39.50

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

Wymagania funkcjonalne określają jakie usługi ma oferować system, jak ma reagować na 
otrzymywane dane wejściowe oraz w określonych sytuacjach. Określają one użytkowników 

korzystających z systemu oraz możliwości każdego z nich. Określają również wykorzystanie 
systemów zewnętrznych. Mogą one również określać czego system nie powinien robić. 

Wymagania funkcjonalne mogą być realizowane przez systemy zewnętrzne. 
Przykłady:

-wprowadzenie nie pełnych danych system powinien komunikować błędem 
-system powinien przydzielać odpowiednie zlecenia pracownikom

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

        informatycznego.
Wymagania niefunkcjonalne są to ograniczenia systemu, które obejmują ograniczenia czasowe, 

ograniczenia dotyczące procesu tworzenia, standardy itd. 
Wynikają one z potrzeb użytkownika, budżetu, potrzeby współpracy z innym systemem, 

strategii firmy i czynników zewnętrznych. Wymagania niefunkcjonalne można podzielić na trzy 
podklasy: 

    Produktowe (określają zachowanie produktu) :
-system powinien być łatwy w użyciu dla doświadczonych kontrolerów

    Organizacyjne (wynikają ze strategii w firmie wytwórczej i firmie klienta) 
-proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i

  produktami zdefiniowanymi w standardzie XYZCo-SP-STAN-95. 
    Zewnętrzne

-system nie powinien ujawniać operatorom żadnych danych osobowych klientów  
  oprócz nazwisk i numerów identyfikacyjnych.

23. Omów metody specyfikacji wymagań dla systemów informatycznych. 
W zależności od potrzeb stosuje się różne 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  tablic, kojarzących różne aspekty.

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

Dokument opisujący wymagania na system informatyczny ma pewien schemat: 
Informacje organizacyjne: 

Streszczenie (około 200 słów),  Spis treści, Statut dokumentu(autorzy, firmy, podpisy), 
Zmiany w stosunku do poprzedniej wersji. 

Zasadnicza zawartość dokumentu: 
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 3.2 Wymagania niefunkcjonalne )

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.

25. Omów zakres fazy analizy w cyklu wytwórczym systemów informatycznych. 
Celem fazy analizy jest ustalenie wszystkich tych czynników, 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.
Zakres fazy analizy:

--Wykracza poza zakres odpowiedzialności systemu -> kontekst użycia i współpracy;
--Ujęcie w modelu pewnych elementów nie będących częścią systemu -> model jest 

    bardziej zrozumiały;
--Abstrakcja modelowania -> podczas modelowania może nie być jasne, 

    które elementy modelu będą realizowane przez oprogramowanie a które w sposób 
    sprzętowy lub ręcznie;

--Dostępne środki mogą nie pozwolić na realizację systemu w całości -> analiza może
    wykryć fragmenty, które mogą być szczególnie ważne;

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

Cechy modelu analitycznego:
--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.

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.

Analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez wprowadzenie tam 
nowych elementów, jej celem jest rozpoznanie wszystkich tych aspektów rzeczywistości, które 

mogłyby mieć wpływ na postać, organizację lub wynik projektu.

27.Omów przykłady nieobiektowego podejścia do analizy, projektu i implementacji 
systemów informatycznych.

Metodyki strukturalne - łączą statyczny opis danych oraz statyczny opis procesów. 

Do tej klasy należą:

•

 Metodyka Yourdona (DeMarco i Ward/Mellor);

•

 Structured System Analysis and Design Methodology (SSADM);

•

 Structured Analysis and Design Technique (SADT).

Uważa się, że wadą metodyk strukturalnych są trudności w zintegrowaniu modeli oraz iż 

pomimo dojrzałości,  mogą nie być adekwatne do współczesnych tendencji wytwarzania 
systemów informatycznych;

Przykład metodyki - CDM-Oracle-1996

–

stosowana do procesów biznesowych i funkcji, które nie mogą być obsłużone za 

pomocą dostępnych aplikacji „z półki”;

–

CDM jest zbiorem zdefiniowanych procesów tworzenia oprogramowania, które 
zostały określone przy założeniu, że w procesie wytwórczym stosowane są 

metody i narzędzia CASE;

–

zakłada, że potrzeby biznesowe zostają wyraźnie zdefiniowane na samym 
początku cyklu projektowego oraz że ich zweryfikowanie jest możliwe podczas 

całego procesu wytwórczego;

CDM wyróżnia następujące procesy:

–

definicja potrzeb biznesowych (studium możliwości),

–

analiza istniejących systemów,

–

opracowanie architektury technicznej,

–

projektowanie i budowa bazy danych,

–

projektowanie i budowa modułów,

–

konwersja danych,

–

opracowanie dokumentacji technicznej,

–

testowanie,

–

szkolenie,

–

przejście na nowy system,

–

obsługa serwisowa;

28.Omów przykłady obiektowego podejścia do analizy, projektu i implementacji 

systemów informatycznych.

/* Pytanie brzmi omów PRZYKŁADY więc jakiś geniusz od poprzedniej ściągi nie bardzo 
zrozumiał pytanie i na przekór nie przytoczył ANI JEDNEGO przykładu metodyki. Jest tego w 

chuja i nie widzę sposobu spamiętania wszystkich tych pierdół w podpunktach. Załączam 
przekroje metodyk z wykładów */

Analiza i Projektowanie - metody obiektowe
Wspólna zasada: zaczynamy od rozpoznania struktury obiektów. Najważniejsze jest, czym są 

obiekty, a nie co robią.
Wspólne kroki wszystkich metod obiektowych:

•

Identyfikacja klas i obiektów, ich atrybutów i metod 

•

Ustalenie  powiązań między obiektami 

•

Ustalenie interfejsu każdego obiektu (protokołu)

•

Ustalenie współpracy obiektów, przepływ informacji 

•

Implementacja, tworzenie prototypu. 

# Przykład- Metoda Coad/Yourdon
5 głównych czynności 

1. znajdowanie klas  i obiektów 
2. identyfikacja struktur 

3. identyfikacja tematów 
4. definiowania atrybutów 

5. definiowania usług 

model analizy obiektowej zawiera 5 warstw 

1. warstwa tematów 
2. warstwa klas i obiektów 

3. warstwa struktury 
4. warstwa atrybutów 

5. warstwa usług 

# Przykłąd Analiza metoda OMT (metoda Rumbaugh)

OMT - Object Modelling Technique
3 części składowe modelu, pokazujące różne jego aspekty:

Model Obiektów (OMT Object Model)
statyczny obraz struktury modelu 

- klasy 
- atrybuty 

- operacje 
- relacje między klasami i instancjami (powiązania - asocjacje, 

całość - część (agregacje),  gen- spec)
Model Dynamiczny (OMT Dynamic Model)

współdziałanie obiektów (powiązania wyznaczone przez komunikaty).
Tu mieszczą się różne diagramy pokazujące przepływ sterowania, 

także ograniczenia i warunki na wartości atrybutów.

Model Funkcyjny (OMT Functional Model) 
specyfikacja operacji jako funkcji przekształacących wejście na 

wyjście, warunki poprawności (asercje). 

# Ogólnie w temacie o analizie obiektowej 
– 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 jest złożoną konstrukcją, której stopień skomplikowania zależy od 
złożoności architektury. Wielkie systemy są zwykle podzielone na podsystemy, które oferują 

pewien zbiór powiązanych ze sobą interfejsów;

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

System informatyczny - jest to zbiór powiązanych ze sobą elementów, którego funkcją jest 
przetwarzanie 

danych

 przy użyciu techniki komputerowej. Na systemy informatyczne składają 

się obecnie takie elementy jak:

•

sprzęt - obecnie głównie 

komputery

, oraz 

o

urządzenia służące do przechowywania danych

o

urządzenia służące do komunikacji między sprzętowymi elementami systemu

o

urządzenia służące do komunikacji między ludźmi a komputerami

o

urządzenia służące do odbierania danych ze świata zewnętrznego - nie od ludzi 
(na przykład czujniki elektroniczne, 

kamery

, 

skanery

)

o

urządzenia służące do wpływania systemów informatycznych na świat 
zewnętrzny - elementy wykonawcze (na przykład 

silniki

 sterowane 

komputerowo, 

roboty

 przemysłowe, podłączony do komputera ekspres do kawy, 

sterowniki urządzeń mechanicznych)

o

urządzenia służące do przetwarzania danych nie będące komputerami

•

oprogramowanie

 

 

•

zasoby osobowe - ludzie

•

elementy organizacyjne - czyli procedury (procedury organizacyjne - termin z 
zarządzania) korzystania z systemu informatycznego, instrukcje robocze itp.

•

elementy informacyjne; bazy wiedzy - 

ontologie

 dziedziny/dziedzin, w których używany 

jest system informatyczny - na przykład podręcznik księgowania w wypadku systemu 

finansowo-księgowego

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 - (Object Diagram)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 - (Component Diagram) (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. Elementami tymi są:  

Komponenty przedstawiane za pomocą dużego prostokąta, 

z dwoma mniejszymi z jego lewej strony oraz z etykietą w środku. Komponenty mogą być 

przedstawiane zarówno jako klasy jak i instancje. Klasa oznacza elementy systemu istniejące 
podczas jego działania (np. interfejs użytkownika czy dane). Konkretne instancje precyzują 

o jaki element chodzi (np. okno programu będące częścią interfejsu).  Węzły są to zasoby 
sprzętowe dostępne podczas działania systemu. Obrazowane są za pomocą 

prostopadłościanów. 

 

Zależności

Diagram pakietów – (Package Diagram)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 ( Use Case Diagram)
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. (State Machine Diagram)

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 (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 dokumentujący zależności między 

elementami danych nazywa się diagramem zależności lub diagramem determinowania.

●

 

Elementy danych rysowane są w postaci owali, kółek lub baniek.

●

 

Zależność funkcyjna oznaczana jest przy pomocy strzałek łączących element determinujący z 

zależnym

Diagram zależności przedstawia kolejność wykonywania wcześniej ustalonych funkcji 

elementarnych. Dotyczy zależności informacyjnych. Jest to tzw. diagram następstw, 
uwzględniający zdarzenia inicjujące wykonanie funkcji oraz ich wyniki. Przedstawia wszystkie 

możliwe drogi postępowania, zatem wymaga użycia operatorów relacji OR, AND i XOR.
 

Diagram przepływu danych - DFD (ang. Data Flow Diagram) . diagramy przepływu danych 
pozwalają na modelowanie procesów w systemie informatycznym lub organizacji. Podstawowe 

elementy diagramów DFD
to:

· proces (ang. process),
· przepływ (ang. flow),

· magazyn inaczej skład/składnica danych (ang. datastore),
· terminator (ang. terminator) inaczej jednostka zewnętrzna (ang external entity).

Każdy z powyższych elementów ma odpowiedni symbol graficzny jednoznacznie wyróżniajacy 
go

na diagramie. Niestety, różne metodyki używają różnej symboliki . zwykle jednak koncepcja i 
semantyka

diagramów jest jednakowa. 

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

/* zagadnienie troche niedopowiedziane, ale możne ładnie wode polać w temacie*/

W analize i projektowaniu systemów inf. rozróżniamy dwa podejścia – strukturalne i obiektowe.

Podejście encja-związek jest strukturalne – diagramy encja-związek występuja w strukturalnej 
metodyce SSADM. Model taki opisuje statyczna strukturę systemu, grupując dane w kolekcje 

zwane
obiektami (encje). Graficznym odpowiednikiem jest diagram ERD (ang. Entity Relationshi

Diagram), którego węzły reprezentują obiekty natomiast łuki odzwierciedlają relacje
pomiędzy obiektami. Przy podejściu bazodanowym, gdy występuje spora ilość danych, 

korzystne jest rozróżnianie rodzajów danych oraz prześledzenie ich przepływu.
Obecnie najbardziej rozpowszechnione jest podejście obiektowe. Cechuje się ono 

przejrzystością oraz wygodą tworzenia modelów. Intuicyjnie dokonywane jest powiązywanie 
metod z danymi, na których one operują. Pomiędzy obiektami można w prostszy sposób 

zamodelować interakcję.
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 projektu informatycznego jest dostarczenie odbiorcy i dostawcy obiektywnych, 

aktualnych i syntetycznych informacji o stanie całego projektu
Pod kątem procesu wytwórczego systemów informatycznych audytowi podlegają produkty 

(cząśtkowe) projektu informatycznego. Ma to na celu sprawdzenie czy rezultaty poszczególnych 
prac odpowiadają zakładanym wymaganiom.

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]

Dla procesów wytwórczego może ona mieć "zbawienny" wpływ gdyż poprawia ona proces 
programowy.

Czas wytworzenia systemu dzięki inspekcji skraca się, gdyż wcześniej dowiadujemy się o 
błedach.

Zwiększa ona także motywację pracowników poprzez obudzenie w nich świadomości, że 
produkt będzie oceniany.

Może mieć ona z kolei zgubny wpływ na etapie opracowywania dokumentów, gdyż 
pracownikowi "rodzi się" w głowie myśl: "inspekcja wskaże błędy".

Po inspekcji, kontrolach indywidualnych i poprawie produktu następuje burza mózgów mająca
na celu identyfikację przyczyn błędów (max 10 najpoważniejszych) i propozycji poprawy 

procesu programowego, by błędy te nie powtórzyły się w przyszłości.
Idee są notowane bez ich głębokiej oceny.

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

informatycznego.

Strategia procesu testowania zależy w dużej mierze od przyjętego modelu cyklu życia 
oprogramowania, rodzaju oprogramowania, dojrzałości zespołu testerów, posiadanych narzędzi 

do testowania.
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 zmniejszyć dokładność badania (potencjalna 
rozbieżność z właściwościami implemetacyjnymi 

Badania diagnostyczne:
 Typy:

 - Analiza dynamiczna

–

eksperymentowanie z działającym kodem programu;

 - analiza statyczna 

–

praca z kodem źródłowym w celu:

»

rozpoznania funkcjonalności testowanego kodu;

»

zaprojektowania odpowiednich testów;

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

Testowanie strategią 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. 
Przykładowy graf strumieni podprogramu wyszukującego binarnie: 

Testowanie strategią czarnej skrzynki - 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.

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;

Zadaniem testera jest taki wybór danych wejściowych, aby z dużym p-stwem były elementami 

zbioru „Wejście-b”;
Dane wejściowe mogą być dzielone na klasy równoważności (dziedziny) o wspólnych cechach 

(np. liczby dodatnie);

»

Zakłada się, że programy działają zwykle w porównywalny sposób dla 
wszystkich elementów jednej klasy;

»

Przypadki testowe projektuje się tak, aby dane wejściowe i wyjściowe 
leżały wewnątrz tych klas;

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.

Proces projektowania architektonicznego polega na ustaleniu podstawowego zrębu 

systemu. Podział architektoniczny jest niezbędny do strukturalizacji i porządkowania 

specyfikacji. Model architektoniczny jest zwykle punktem początkowym do specyfikowania 
rozmaitych części systemu. Obejmuje identyfikację najważniejszych komponentów systemu i 

komunikacji między nimi. Wyróżnia się składowe procesy projektowania architektonicznego:
2. Strukturalizacja systemu

1. System jest dzielony na kilka podstawowych podsystemów, przy czym podsystem 

jest niezależną jednostką oprogramowania

2. Identyfikuje się tu komunikację między podsystemami

3. Modelowanie sterowania

1. Określa się ogólny model związków sterowania między częściami systemu

Podział na moduły

Każdy zidentyfikowany podsystem jest dzielony na moduły
Architekt musi wskazywać typy modułów i ich połączenia

Wynikiem projektowania architektonicznego są dokumentacja zawierająca modele graficzne i 
opisy tekstowe oraz modele przedstawiające rozmaite perspektywy architektury.

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

Wzorzec projektowy jest to uniwersalne, sprawdzone w praktyce rozwiązanie często 

pojawiających się, powtarzalnych problemów projektowych. Wzorce projektowe zwiększają 
elastyczność, wielokrotne wykorzystanie oraz czytelność projektu, dostarczają sprawdzonych 

rozwiązań dla powtarzających się problemów, wpływają na sposób modelowania, usprawniają 
komunikację oraz tworzenie dokumentacji.

Podział wzorców 1:

−

Analityczne – ułatwiają modelowanie dziedziny

−

Projektowe – opisują pewne techniki projektowe

−

Architektury – standardowe rozwiązania architektury

−

Organizacyjne – opisują organizację pracy zespołu

Podział wzorców 2:

−

Konstrukcyjne

−

wykorzystywane do pozyskiwania obiektów zamiast ich bezpośredniego tworzenia

−

Strukturalne

−

stosowane do łączenia obiektów w większe struktury

−

Operacyjne

−

definiowanie komunikacji pomiędzy obiektami

−

kontrolowanie przypływu danych w złożonych algorytmach (programach)

−

przydział zobowiązań obiektom

Podział wzorców 3:

−

Warstwy prezentacji

−

Warstwy logiki

−

Warstwy integracji

42.Omów wzorzec projektowy …… (nazwa jednego z wzorców z wykładu).

Jak wyżej

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

−

wykrywanie błędów jest niezależne

−

usuwanie wykrytych błędów nie generuje nowych

−

intensywność wykrywana błędów – proporcjonalna do liczby błędów pozostających w 

oprogramowaniu:

gdzie:

K – stała

Er – wspł. pozostających błędów
Et – stała – początkowa liczba błędów w programie

It – stała – liczba instrukcji w programie
Ec – łączna unormowana liczba błędów usuniętych w przedziale [0, (tał)] :)

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

z(

τ

)

K(E

T

/I

T

ε

C

(

τ

)

E

T

/I

szacunki kosztów.

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

Koszty oprogramowania złej jakości

1. Koszty jakości

•

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łądy)

3. Straty jakości (skutki odchyleń od wymagań jakościowych)

•

testowanie: 30%-40% całkowitej pracochłonności

•

testowanie systemów krytycznych: 70%-80% całkowitej pracochłonności

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

Testowanie: sprawdzanie, czy system działa tak, jak założono w specyfikacji.
Przykłady:

–Testowanie komponentów: 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;

Weryfikacja: testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie 

określenia wymagań. 
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ą. 

Przykłady:

-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

-Audyt.

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

Badanie prognostyczne: badanie 

gdy nie ma jeszcze kodu. Zanim powstanie implementacja oprogramowania, jego przyszłe 
działanie jest badane na podstawie założeń analitycznych/ projektowych. 

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 zmniejszyć dokładność badania (potencjalna 

rozbieżność z właściwościami implemetacyjnymi).

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

Badanie diagnostyczne: badanie gdy istnieje kod źródłowy; Składa się z:

-Analiza dynamiczna: eksperymentowanie z działającym kodem programu;
-Analiza statyczna: praca z kodem źródłowym w celu rozpoznania funkcjonalności testowanego 

kodu i
zaprojektowania odpowiednich testów;

-wykrywanie anomalii: 
defekt: nieprawidłowe działanie człowieka w procesie wytwarzania, np. złe sformułowanie 

wymagań, zła decyzja projektowa, pomyłka w implementacji;
–Błąd: każde zdarzenie, w wyniku którego kod produkuje nieoczekiwany rezultat;

–Awaria: stan, w którym program nie jest zdolny wykonać prawidłowo co najmniej jednej ze 
swoich funkcji;

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

jakości.

Drugi poziom to: ADEKWATNOŚĆ
:

-Kompletność

-Racjonalność funkcjonalna

-Racjonalność komunikacyjna

-Zwartość funkcjonalna

-Zwartość komunikacyjna
Tu niestety nichuja nie ma w wykładach a w necie tez niewiele znalazłem, ale dosyć intuicyjne 

wiec można polać wodę.

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

błędy wymagań i analizy: złe sformułowanie problemu, zaniedbanie istotnych parametrów, 
niewłaściwy algorytm

błędy projektowania: błędna interpretacja wymagań, błędy logiczne
błędy opracowania (danych)  szczegółowej struktury programu: zła interpretacja wymagań 

dla   programu,   niepełność   struktury   programu,   nie   uwzględnienie   przypadków   szczególnych, 
niedostateczne dopracowanie błędów, zlekceważenie warunków czasowych;

błędy   kodowania:  syntaktyczne,   zazwyczaj   rozpoznawane   przez   kompilator,   błędy 
merytoryczne   (nieprawidłowe   korzystanie   z   indeksów   i   wskaźników,   zły   przydział   pamięci, 

pominięcie inicjalizacji zmiennych, pomieszanie parametrów funkcji, błąd w pętlach, zamiana 
wyników decyzji w instrukcjach warunkowych, błędy deklaracji typów i wymiarów danych, błędy 

zakresów wartości danych, 
błędy kompilacji i konsolidacji: błędy kompilatora, błędy w zakresach nazw itp.

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

Testowanie komponentów <-> Testowanie modułów <-> testowanie podsystemów <-> 

testowanie systemów <-> testowanie odbiorcze;
-testowanie komponentów: 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: Podsystemy zintegrowano już w system. Ten proces testowania ma 

wykryć błędy wynikające z nie przewidzianych interakcji między 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.

Przypadek testowy (ang. test case) - specyfikacja:
-stan początkowy, czyli stan testowanego systemu (lub jego fragmentu) przed testem, 

-dane wejściowe,
-warunki testu, 

-dane wyjściowe (oczekiwane wyniki);
-Jakość przypadku testowego :

prawdopodobieństwo znalezienia jeszcze nie wykrytego błędu;

Test zakończony powodzeniem:

WYKRYWA dotychczas nie wykryty błąd;
      [G. Myers, The Art. Of Software Testing, 1979]

Określone w rozporządzeniu ministra nauki i informatyzacji z 19 października 2005:
przypadek testowy — test akceptacyjny obejmujący pojedynczy zestaw danych wejściowych 

wprowadzanych do oprogramowania testowanego;
scenariusz testowy — zestaw co najmniej dwóch przypadków testowych powiązanych ze 

sobą w taki sposób, że danymi wejściowymi do każdego kolejnego przypadku testowego są 
niezmienione dane wyjściowe z poprzedzającego go przypadku testowego;

53.Co to jest macierz przykrycia testów akceptacyjnych? Podaj przykłady.
Macierz przykrycia testów akceptacyjnych jest to macierz opisująca wszystkie funkcjonalności 

oprogramowania oraz powiązane z nimi przypadki testowe. Pozwala na wykrycie 
nietestowanych funkcjonalności oraz nadmiarowych testów (nie testujących żadnej 

funkcjonalności).

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;

–

wstępujące (oddolne) - testuje się i integruje komponenty niskiego poziomu 
przed ukończeniem  budowy komponentów wyższego poziomu;

-Testowanie interfejsu jest wykonywane po zintegrowaniu modułów lub podsystemów w 

większe systemy.
-Każdy moduł i podsystem ma zdefiniowany interfejs, który jest wywoływany przez inne 

komponenty programu, np.:

–

Interfejsy parametryczne,

–

Interfejs w pamięci dzielonej,

–

Interfejsy proceduralne, 

–

Interfejsy z przekazywaniem komunikatów;

-Celem testowania interfejsu jest wykrycie usterek, które pojawiły się w systemie z powodu 

błędów w interfejsach lub nieprawdziwych założeniach o interfejsach.

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

- służą do pozyskiwania obiektów;
- szczegółowo opisują jaki obiekt może zostać stworzony;

- uniezależniają kod od typów tworzonych obiektów (zależne jest to tylko od parametrów 
konfiguracyjnych);

Przykłady:

-Singelton-

-Zapewnia powołanie tylko jednej instancji obiektu w całej aplikacji i kontrolowany 

dostęp;
-Obiekt powołany wg tego wzorca jest globalnym punktem dostępu do instancji danej 

klasy ;
-Wzorzec może być zmodyfikowany do tworzenia określonej liczby instancji danej klasy 

(>1);
-Funkcje wzorca: utworzenie obiektu, inicjalizacja obiektu, punkt dostępu, modyfikacja 

obiektu;
-Prostszym rozwiązaniem jest: globalnie dostępna zmienna statyczną przechowująca 

referencję do obiektu;

-metoda fabrykująca;

Fabryka nie może przewidzieć, jakie obiekty i w jaki sposób tworzyć;

Klient zna tylko interfejs klasy abstrakcyjnej;

Informacje o sposobie i odpowiedzialność za tworzenie obiektu znajdują się w 
implementacjach „metody tworzącej” klas pochodnych;

Można tworzyć domyślny produkt, ale też dać użytkownikowi możliwość podstawienia 
swojej wyspecjalizowanej wersji;

-fabryka abstrakcyjna;
-fabryka;

-Fabryka nowych obiektów w zdefiniowanych klasach wzorcowych;
Wszystkie klasy wzorcowe mają metody o tej samej nazwie, ale o innych realizacjach;

Zaleta – możliwość modyfikowania klas wzorcowych (tworzących) w jednym miejscu 
projektu;

Popularne wersje Fabryki: Metoda Fabrykująca, Fabryka Abstrakcji, Budowniczy, 
Prototyp;

-budowniczy;
-prototyp.

Podsumowanie:

Singleton – pojedyncza instancja obiektu;
Metoda Fabrykująca – tworzenie obiektów w klasach pochodnych;

Fabryka Abstrakcyjna – tworzenie rodzin obiektów bez wydzielonych klas fabryk;
Budowniczy – ukrycie szczegółów tworzenia za interfejsem zarządcy;

Prototyp – tworzenie kopii na podstawie w pełni zainicjalizowanej instancji;

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



Stosowany do łączenia obiektów w większe struktury;



Zastosowanie np. w implementacji złożonego interfejsu użytkownika;



Przykłady:



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;



Przykłady:



w bibliotekach Javy: klasy pakietu java.sql (Statement, ResultSet);



wejście usług w Service Oriented Architecture (SOA);



Adapter,



Konwertuje (dopasowuje) interfejsy jednej klasy do interfejsu innej klasy; 



Umożliwia klasom o różnych interfejsach współpracę w jednym 

programie;



Niewielka elastyczność – adaptacji podlega tylko jedna klasa (Adaptee), 

bez jej podklas;



Zmiana zachowania klasy Adapter może zmienić zachowanie klasy 

dostosowywanej Adaptee;



Dwa sposoby realizacji: 



dziedziczenie,



kompozycja;



Most,



Kompozyt,



System złożony z podsystemów o strukturze drzewiastej ( reprezentacja 
związku „całość-część”);



Wspólny interfejs dla klas węzłów i liści – ujednolicone widzenie 
kontenerów i obiektów składowanych;



Łatwo rozszerzalny o nowe podsystemy implementujące (określony 
interfejs);




Przykłady:



Przykład w bibliotekach Javy: kontenery (Panel, JComponent, …);



Dekorator,



Waga Piórkowa,



Zastąpienie wielu obiektów jednym współdzielonym z opisem stanu 
zubożonym w porównaniu z pierwotnym obiektem;



Zamiast przechowywać wewnątrz atrybuty stanu, obiekty dostają 
wartości z zewnątrz jako parametry wywołania metod; 



Zalety:



Ograniczenie liczby tworzonych instancji obiektów;



Przesunięcie części danych z obiektu do przekazywanych parametrów 
metod;



Wady:



Zwiększony koszt wywoływania metod obiektów;



Uzyskuje się przyspieszenie programów operujących na wielu niezbyt 
złożonych obiektach;



Przykład: zbiory obiektów „znaków literowych”; 



Proxy;

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



W celu definiowania komunikacji pomiędzy obiektami;



Pomagają kontrolować przepływ danych w złożonym programie;



Przykłady:



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;




Przykład:



W bibliotekach Javy: iterator w kolekcjach z pakietu java.util;



Łańcuch Odpowiedzialności,



Zestaw klas obsługuje żądanie w określonej kolejności;



Żądanie jest przekazywane pomiędzy klasami w określonym łańcuchu;



Czasami ostatni obiekt łańcucha obsługuje wszystkie żądania;




Przykład:



Realizacja w Javie: Frame -> Panel -> Component; 



Stan,



Tworzy obiekty pochodne z bazowej klasy State dla każdego stanu, w 
którym może znaleźć się aplikacja; 



Przełączanie pomiędzy obiektami stanu, gdy zmieni się stan aplikacji;



Wraz ze zmianą stanu i tym samym obiektu może zmienić się zachowanie 

obiektu (inne implementacje metod);



Eliminuje złożone instrukcje warunkowe (np. switch) w metodach obiektu;



Wada: powstaje wiele małych klas;



Zaleta: upraszcza program;



Mediator,



Mediatora stanowi „zarządcę obiektów”;



Wprowadza luźniejsze powiązania pomiędzy klasami – obiekty znają 
Mediatora a nie koniecznie inne obiekty;



Zmiany stanu obiektów są za jego pośrednictwem (odpowiednich metod) 
propagowane do zainteresowanych obiektów;



Często jest specjalizowany dla jednego projektu;



Obserwator,



Strategia;



Potrzeba kilku wariantów algorytmu;



Wybór określonego wariantu poprzez powołanie obiektu pochodnego do 
zdefiniowanego interfejsu  bazowego lub klasy abstrakcyjnej;



Każda wersja algorytmu jest implementowana w osobnej klasie;



Zalety:



algorytm może używać danych, których klient nie zna;



hermetyzacja algorytmów w oddzielnych klasach pozwala na ich 

modyfikację niezależnie od kontekstu;



to rozwiązanie zastępuje instrukcje wyboru lub warunkowe;