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;