1.Omów przedmiot i zakres inżynierii
wprowadzane są poprawki dopóki klient nie
oprogramowania.
Inżynieria oprogramowania to dziedzina inżynierii
systemów zajmująca się wszelkimi aspektami produkcji
oprogramowania: od analizy i określenia wymagań,
przez projektowanie i wdrożenie, aż do ewolucji
gotowego oprogramowania. Podczas gdy informatyka
zajmuje się teoretycznymi aspektami produkcji
oprogramowania, inżynieria oprogramowania
koncentruje się na stronie praktycznej.
W inżynierii oprogramowania proces produkcji
oprogramowania dzieli się na pewne fazy, typowy
podział to:
1. specyfikacja - na tym etapie następuje określenie i
ustalenie wymagań, które musi spełniać
oprogramowanie
2. projektowanie - ustalenie ogólnej architektury
systemu, wymagań dla poszczególnych jego
składowych
3. implementacja - realizacja ustalonej architektury
poprzez implementację składowych (modułów) i
połączeń między nimi.
4. integracja - zintegrowanie poszczególnych
składowych w jeden system, testowanie całego systemu
5. ewolucja - uruchomienie systemu, usuwanie
wykrytych podczas jego używania błędów, rozszerzanie
systemu
2.Omów zagadnienie języka programowania i
semiotyki języka programowania.
Semiotyka 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
Zapis algorytmu w języku programowania jest
traktowany jako zapis formalny. Program komputerowy
jest uznawany za jeden z rodzajów modeli
matematycznych. Jest to algorytmiczny model zadania
czy też rzeczywistości, którą modelujemy.
3.Omów zagadnienie i skutki tzw. „kryzysu
oprogramowania”.
Kryzys oprogramowania (ang. software crisis) —
zjawisko dostrzeżone już w latach 60. Polega na
powiększającej się rozbieżności między mocą
obliczeniową sprzętu komputerowego a efektywnością
produkcji oprogramowania. Wysiłki informatyków
zmierzają do optymalizacji procesu wytwarzania
oprogramowania poprzez stosowanie odpowiednich
metod i technik szczegółowych w tym zakresie.
4.Omów przykładowe źródła złożoności projektu
informatycznego.
Najczęstsze ryzyko związane z realizacją projektów IT
wynika z braku kompetencji samych użytkowników,
opóźnień w prowadzeniu przedsięwzięcia oraz źle
zaplanowanego i przekroczonego budżetu. Istnieje
również grupa ryzyk wiążących się z nagłą zmianą
priorytetów, reorganizacją struktur i zasobów oraz
rotacją ludzi w zespołach.
W przypadku zarządzania ryzykiem szefowie IT
stawiali przede wszystkim na własne siły. Jedynie
nieliczni decydowali się na wybór zewnętrznego
doradcy. Kolejna przeszkoda wynika z długiego
procesu decyzyjnego oraz oporu kierownictwa
wyższego szczebla.
5.Omów sposoby opanowywania złożoności projektu
informatycznego.
Aby wałczyć ze zjawiskiem złożoności projektu,
stosuje się:
ZASADE DEKOMPOZYCJI
Czyli rozdzielenie złożonego problemu na
podproblemy,
ZASADE ABSTRAKCJI
Czyli eliminacja mniej istotnych szczegółów
rozważanego przedmiotu, wyodrębnianie cech
wspólnych pewnego zbioru bytów i wprowadzaniu
pojęć oznaczających te cechy.
ZASADE PONOWNEGO UZYCIA
Czyli wykorzystanie wcześniej wytworzonych
schematów, metod,
ZASADE SPRZYJANIA NATURALNYM LUDZKIM
WLASNOSCIOM
Czyli dopasowanie modeli pojęciowych i modeli
realizacyjnych systemów do wrodzonych ludzkich
zdolności
6.Omów zagadnienie modelowania pojęciowego w
projekcie informatycznym.
Pojęcia modelu pojęciowego odnosi się do procesów
myślowych i wyobrażeń towarzyszących pracy nad
oprogramowaniem. Jest wspomagane przez środki
wzmacniające wyobraźnię. Służą one do przedstawienia
rzeczywistości opisywanej przez dane, procesów
zachodzących w rzeczywistości
7. Co to jest metodyka prowadzenia projektu
informatycznego?
Metodyka jest to zestaw pojęć, notacji, modeli, języków,
technik i sposobów postępowania służący do analizy
dziedziny stanowiącej przedmiot projektowanego systemu
oraz do projektowania pojęciowego, logicznego i/lub
fizycznego.
8. Omów następujący model cyklu życia
oprogramowania: … nazwa modelu
Model kaskadowy: zawiera ciąg czynności
wykonywanych sekwencyjnie przy tworzeniu
oprogramowania:
-określenie wymagań
-analiza
-projektowanie
-implementacja
-testowanie
-konserwacja
wady: Narzucenie twórcom oprogramowania ścisłej
kolejności wykonywania prac
Wysoki koszt błędów popełnionych we wczesnych fazach
Długa przerwa w kontaktach z klientem
Wytwarzanie ewolucyjne
polega na:
opracowaniu wstępnej implementacji,
pokazaniu jej użytkownikowi z prośbą o komentarze
oraz udoskonalaniu jej w wielu wersjach aż do powstania
odpowiedniego systemu;
wyróżnia się tworzenie badawcze (praca z klientem) oraz
prototypowanie (praca z elementami systemu budzącymi
wątpliwości)
prototypowanie:
Sposób na uniknięcie zbyt wysokich kosztów błędów
popełnionych w fazie określania wymagań. Zalecany w
przypadku, gdy określenie początkowych wymagań jest
stosunkowo łatwe.
fazy
- ogólne określenie wymagań
- budowa prototypu
- weryfikacja prototypu przez klienta
- pełne określenie wymagań
- realizacja pełnego systemu zgodnie z modelem
kaskadowym
model V
polega na 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ól
odpowiada wyłącznie za ocenę i testowanie systemu. testy
odbywają się od zadań, potem przechodzą do testowania
podsystemów, a następnie testowany jest pełny system.
model spiralny
opiera się na ewolucyjnym projekcie, który jest
początkowo planowany, następnie wykonywana jest
analiza ryzyka systemu, konstrukcja (często odbywa się
zgodnie z modelem kaskadowym) a potem klient testuje
system, informuje, co wymaga zmian i poprawek, i
zgodnie z nimi cały cykl rozpoczyna się od początku, w
kolejnym obrocie pętli do istniejącego systemu
zaakceptuje systemu.
9 Omów zadania kierownictwa przedsięwzięcia
informatycznego w cyklu wytwórczym
oprogramowania.
Podstawowe zadania kierownictwa przedsięwzięcia
informatycznego:
- Opracowanie propozycji dotyczących sposobu
prowadzenia przedsięwzięcia
- Kosztorysowanie przedsięwzięcia
- Planowanie i harmonogramowanie przedsięwzięcia
- Monitorowanie i kontrolowanie realizacji
przedsięwzięcia
- Dobór i ocena personelu
- Opracowanie i prezentowanie sprawozdań dla
kierownictwa wyższego szczebla
10 Omów podstawowe czynniki psychologiczne w
procesie wytwórczym i rodzaje osobowości
twórców oprogramowania
Czynniki te wynikają z faktu, że oprogramowanie
jest używane i tworzone przez ludzi.
Użytkowanie - implikuje zasady tworzenia interfejsu
użytkownika i dokumentacji użytkowej,
Tworzenie - zagadnienia psychologiczne
odgrywające rolę w tworzeniu oprogramowania.
Elementy ludzkiej inteligencji:
Umiejętność całościowego (syntetycznego)
spojrzenia na problem.
Posługiwanie się wiedzą płynącą z doświadczenia, a
więc stosowania nieścisłych zasad wnioskowania na
bazie wcześniejszych doświadczeń.
Istnieją ogromne różnice w predyspozycjach osób
dotyczące ich efektywności w produkcji
oprogramowania.
Testy osobowości:
metody określenia, czy dana osoba posiada cechy
przydatne na danym stanowisku.
Stosowanie testów osobowości wiąże się z
następującymi trudnościami:
Osobowość ludzka ma charakter dynamiczny
(zmienia się). Wieloletnia praktyka zawodowa nie
pozostaje bez wpływu na osobowość.
Różne zadania mogą wymagać różnych cech
osobowości. Inne powinien posiadać analityk
(kontakt z klientem), inne zaś programista lub osoba
testująca oprogramowanie. Ponadto, metody
inżynierii oprogramowania ulegają zmianie, co
pociąga za sobą inny stosunek pożądanych cech
osobowości do aktualnych zadań.
Osoby poddane testom będą starały się raczej
odgadnąć pożądaną przez testujących odpowiedź niż
odpowiadać zgodnie ze stanem faktycznym. Test nie
będzie więc odzwierciedlał cech osobowości osoby,
lecz raczej to, jak ta osoba wyobraża sobie cele i
kryteria testowania oraz cechy pożądane przez
pracodawcę
11 Omów cechy dobrego inżyniera
oprogramowania i sposoby zorientowania na
pracę w cyklu wytwórczym oprogramowania.
Umiejętność pracy w stresie. W pracy często
zdarzają się okresy wymagające szybkiego
wykonania złożonych zadań. Dla większości osób
niewielki stres działa mobilizująco. Po
przekroczeniu jednak pewnego progu następuje
spadek możliwości danej osoby. Próg ten jest różny
dla różnych osób.
Zdolności adaptacyjne. Informatyka jest jedną z
najszybciej zmieniających się dziedzin. Ocenia się,
że 7-9 miesięcy przynosi w informatyce zmiany,
które w innych dziedzinach zajmują 5-7 lat. Oznacza
to konieczność stałego kształcenia dla wszystkich
inżynierów oprogramowania - stałe poznawanie
nowych narzędzi, sprzętu, oprogramowania,
technologii, metod, sposobów pracy. Niestety, nie
wszyscy to tempo wytrzymują.

Uśpienie, zajmowanie się jednym problemem w
jednym środowisku przez lata jest w informatyce
bardzo groźne!
Wyróżnia się następujące typy psychologiczne:
1. Zorientowani na zadania (task-oriented). Osoby
samowystarczalne, zdolne, zamknięte, agresywne,
lubiące współzawodnictwo, niezależne.
2. Zorientowani na siebie (self-oriented). Osoby
niezgodne, dogmatyczne, agresywne, zamknięte,
lubiące współzawodnictwo, zazdrosne.
3. Zorientowani na interakcję (interaction-oriented).
Osoby nieagresywne, o niewielkiej potrzebie autonomii
i indywidualnych osiągnięć, pomocne, przyjazne.
Osoby typu 1 są efektywne, o ile pracują w pojedynkę.
Zespół złożony z takich osób może być jednak
nieefektywny. Lepsze wyniki dają zespoły złożone z
typów 3. Typ 1 i 2 może być także efektywny w
zespole, o ile jest odpowiednio motywowany przez
kierownictwo. Typy 3 są konieczne w fazie wstępnej
wymagającej intensywnej interakcji z klientem.
12 Omów podstawowe obszary zarządzania
przedsięwzięciem informatycznym według Prince2
Projekt, to sposób prowadzenia przedsięwzięć
gospodarczych zmierzający do wytworzenia produktu
uzasadnionego biznesowo, w ramach określonego
czasu, budżetu, z odpowiednią strukturą organizacyjną ,
rolami i zakresami odpowiedzialności.
Wymiary zarządzania: produkt, Koszt, Harmonogram,
Jakość.
Poszczególne wymiary zarządzania projektem mają na
siebie istotny wpływ. Powinny być one analizowane
przez kierownika projektu łącznie (również ocena
ryzyka)
Przez produkty projektu rozumie się wszystkie jego
elementy, które mogą powstać w wyniku jego realizacji
Często spotykaną formą prezentacji harmonogramu są
na przykład tabele lub arkusze kalkulacyjne, jak
również wykresy Gantta.
Budżet projektu stanowi zestawienie kosztów realizacji
projektu.
Wymiar jakości dotyczy:
- oceny zarówno poszczególnych produktów
projektowych:
- dokumentacji,
- oprogramowania,
- platformy techniczno-systemowej itp.
13. Omów przykład struktury biura projektu
informatycznego, zbudowanego według zaleceń
Prince2.
Sponsor Projektu-członek zarządu klienta lub jego
bezpośredni
przedstawiciel, odpowiedzialny za finansowanie całego
przedsięwzięcia
mają prawo do wglądu w projekt i podejmowanie
decyzji na temat jego
dalszego rozwoju
Rada Projektu- zawiera w swoim ciele reprezentację
wszystkich
uczestników projektu, takich jak: Sponsor,
użytkownicy,
dostawcy, mianowanie Szefów Projektu, okresowa i
etapowa ocena stanu
projektu i zatwierdzanie planów dalszych prac,
rozstrzyganie sporów
występujących na szczeblu Szefów Projektu,
zatwierdzanie Wniosków o
Zmianę w zakresie funkcjonalnym i niefunkcjonalnym
projektu, zatwierdzanie akceptacji kolejnych produktów
projektu
Szefowie projektu-prowadzą i gromadzą dokumentację
projektu, zapewniają warunki pracy zespołów
realizacyjnych, realizują
zatwierdzone zmiany, w zależności od potrzeb zajmują
eskalacją
odpowiednich problemów
Szef Jakości współpracuje z Szefami Projektu i sprawdza
jakość całego projektu ponieważ podlegają mu plany,
dokumentacja projektu wraz z produktami i ich testami.
Komitet Kontroli Zmian składa się z przedstawicieli
zarówno dostawcy jak i klienta. Jego skład wyznacza
Rada Projektu.
Komitet Akceptacyjny składa się przeważnie z
przedstawicieli obu stron, często jednak spotyka się w nim
wyłącznie przedstawicieli klienta (przyjęcie lub
odrzucenie produktu).
Sekretariat/administracja biura projektu- prowadzi
archiwum projektu (zawiera się w nim biblioteka projektu,
zbiory raportów oraz zajmuje się rozliczeniami
finansowymi).
Zespoły Realizacyjne- (odwalaja cały ten syf) relaizują
projekt, szefami sa przeważnie osoby doświadczone w
zakresie tematu projektu
14. Omów podstawowe obszary zarządzania
przedsięwzięciem informatycznym według metodyki
PMI.
Zakres-projekt zawiera tylko to co potrzeba (inicjowanie
faz
projektu
planowanie zakresu
definiowanie zakresu
weryfikacja zakresu
kontrola zmian zakresu )
Koszt-obejmuje procesy wymagane do zapewnienia, że
projekt zostanie ukończony w ramach zaakceptowanego
budżetu
Czas-projektu obejmuje procesy wymagane do
zapewnienia przestrzegania przez zespół projektowy
ustalonych granic czasowych
dla poszczególnych czynności w projekcie
Jakość-obejmuje procesy wymagane do zapewnienia
zaspokojenia przez rezultaty projektu tych potrzeb, dla
których został on powołany
Komunikacja-obejmuje procesy służące zapewnieniu
terminowego i właściwego tworzenia, gromadzenia,
rozpowszechniania, przechowywania i usuwania
informacji niezbędnej do efektywnego zarządzania
projektem
Integracja-obejmuje procesy wymagane do zapewnienia
poprawnej koordynacji wszystkich elementów projektu
Ryzyko-obejmuje procesy identyfikacji, analizowania i
reakcji na zaistnienie czynników ryzyka w projekcie
Ludzie-obejmuje procesy ułatwiające efektywne
wykorzystanie ludzi w projekcie
Zaopatrywanie-obejmuje zdobywanie dóbr i usług spoza
organizacji wykonującej projekt
15. Omów przykład struktury biura projektu
informatycznego, zbudowanego według zaleceń
metodyki Chestra SBS.
Silna pozycja Kierownika Projektu (Szefa Projektu),
zakres projektu i zakres produktu jest określany przez
Architekta Systemowego i Architekta Biznesowego,
Menedżer Jakości podlega pod Szefa Projektu
Menedżer Konfiguracji nie jest już składową administracji
projektu wyróżniono obszary dokumentacji i testów
16. Porównaj zalecenia Prince2, PMI i Chestra SBS w
zakresie obszarów zarządzania projektem
informatycznym i organizacji biura projektu
informatycznego.
PRINCE2:
*dobre*
-Stosowanie tej metodyki zapewnia wysoką
standaryzację i powtarzalność projektów o
wspólnym podejściu, terminologii i dokumentacji.
Zapewnia to możliwość doskonalenia kompetencji.
-Metodyka w sposób racjonalny opiera się na
najlepszych praktykach w zarządzaniu projektami
-Sprawuje kontrolę nad startem, realizacją i końcem
projektu
-Jej stosowanie nie wymaga opłat autorskich
*złe*
-zbyt pracochłonne w zastosowaniu do małych
projektów
-ciągła wymiana informacji powoduje pojawienie się
bezproduktywnych spotkań zabierających czas
niezbędny na rzeczywistą pracę
17.Omów zagadnienie zarządzania konfiguracją
w przedsięwzięciu informatycznym na podstawie
metodyki RUP.
Zarządzania konfiguracją (configuration
management) - jest odpowiedzialne za
systematyczne strukturalizowanie produktów.
Artefakty takie jak dokumenty i modele muszą być
wersjonowane (version control) a zmiany muszą być
widoczne. W skład zarządzania konfiguracją
wchodzi także utrzymywanie rejestru zależności
pomiędzy artefaktami, tak, aby wszystkie powiązane
części były uaktualniane wraz ze zmianami.
18.Omów zakres działania tzw. „inżynierii
wymagań” w procesie wytwórczym
oprogramowania.
W procesie inżynierii wymagań możemy wyróżnić
cztery główne fazy:
1. Studium wykonalności,
- Wynikiem tego studium powinien być raport, który
zaleca albo nie zaleca kontynuacji procesu inżynierii
wymagań i tworzenia systemu.
- Studium wykonalności to krótkie, skumulowane
opracowanie, w którym staramy się odpowiedzieć na
kilka pytań:
a. Czy system przyczyni się do realizacji ogólnych
celów przedsiębiorstwa?
b. Czy system może być zaimplementowany z
użyciem dostępnych technologii, w ramach
ustalonego budżetu i ograniczeń czasowych?
c. Czy system może być zintegrowany z istniejącymi
systemami, które już zainstalowano?
2. Określenie i analiza wymagań,
- W trakcie tej czynności techniczni budowniczowie
oprogramowania pracują z klientem i
użytkownikami systemu nad badaniem dziedziny
zastosowania i usług, które system ma oferować,
pożądanej efektywności, ograniczeniach
sprzętowych itd.
3. specyfikowanie wymagań,
- to częściowo ustrukturalizowany zapis
wykorzystujący zarówno język naturalny, jak i
proste, częściowo przynajmniej sformalizowane
notacje.
4. zatwierdzanie wymagań;
- Polega na wykazaniu, że wymagania naprawdę
definiują system, którego chce użytkownik
- Błędy w wymaganiach kosztują tak dużo, że warto
te wymagania zatwierdzać
Poprawianie błędów w wymaganiach może
kosztować sto razy mniej niż poprawianie błędów w
implementacji.
Inżynieria wymagań ma na celu ma na celu
określenie, jakich usług wymaga się od systemu i
jakim ograniczeniom podlega tworzenie i działanie
oprogramowania;
19.Omów podstawowe metody rozpoznawania
wymagań i cechy jakościowego dobrego opisu
wymagań.
Podstawowe metody rozpoznania wymagań:
- Wywiady i przeglądy. Wywiady powinny być
przygotowane (w postaci listy pytań) i podzielone na
odrębne zagadnienia. Podział powinien przykrywać
całość tematu i powinny być przeprowadzone na
reprezentatywnej grupie użytkowników.
Wywiady powinny doprowadzić do szerokiej zgody i
akceptacji projektu.
- Studia na istniejącym oprogramowaniem. Dość często
nowe oprogramowanie zastępuje stare. Studia powinny
ustalić wszystkie dobre i złe strony starego
oprogramowania.
- Studia wymagań systemowych. Dotyczy sytuacji,
kiedy nowy system ma być częścią większego systemu.
- Studia osiągalności. Określenie realistycznych celów
systemu i metod ich osiągnięcia.
- Prototypowanie. Zbudowanie prototypu systemu
działającego w zmniejszonej skali, z uproszczonymi
interfejsami.
Cechy jakościowego dobrego opisu wymagań:
Dobry opis wymagań powinien:
- Być kompletny oraz niesprzeczny.
- Opisywać zewnętrzne zachowanie się systemu a nie
sposób jego realizacji.
- Obejmować ograniczenia przy jakich musi pracować
system.
- Być łatwy w modyfikacji.
- Brać pod uwagę przyszłe możliwe zmiany wymagań
wobec systemu.
- Opisywać zachowanie systemu w niepożądanych lub
skrajnych sytuacjach
20.Omów główne klasy wymagań na system
informatyczny. Podaj przykłady takich wymagań.
Wymagania funkcjonalne
– Są stwierdzeniami, jakie usługi ma oferować system,
jak ma reagować na określone dane wejściowe oraz jak
ma się zachowywać w określonych sytuacjach.
– W niektórych wypadkach wymagania funkcjonalne
określają, czego system nie powinien robić.
– Mogą być również wykonywane przy użyciu
systemów zewnętrznych.
Przykład:
a) Użytkownik będzie mógł przeszukać zbiór
wszystkich baz danych lub wybrać tylko ich podzbiór.
b) System udostępni odpowiednie narzędzia do
oglądania, aby użytkownik mógł czytać dokumenty z
magazynu.
Wymagania niefunkcjonalne
– To ograniczenia usług i funkcji systemu.
– Obejmują ograniczenia czasowe, ograniczenia
dotyczące procesu tworzenia, standardy itd.
Przykład:
a) System powinien być łatwy w użyciu dla
doświadczonych kontrolerów, a sposób jego organizacji
powinien zmniejszać liczbę błędów użytkownika.
b) Doświadczeni kontrolerzy powinni móc używać
wszystkich funkcji systemu po szkoleniu trwającym
dwie godziny. Po tym szkoleniu średnia liczba błędów
robionych przez doświadczonych użytkowników nie
powinna przekroczyć dwóch dziennie.
Wymagania dziedzinowe
– Są wyrażone za pomocą języka specyficznego dla
dziedziny zastosowania;
– Pochodzą z dziedziny zastosowania systemu -
odzwierciedlają jej charakterystykę.
– Mogą być funkcjonalne lub niefunkcjonalne..
Przykład: wymagania stawiane systemowi biblioteki
a) Wszystkie bazy danych powinny być dostępne przez
jednolity interfejs użytkownika, którego podstawą jest
standard Z39.50.
b) względu na ochronę praw autorskich niektóre
dokumenty należy składać natychmiast po ich
otrzymaniu. Zależnie od wymagań użytkownika,
dokumenty te będą drukowane lokalnie na serwerze
systemowym i przekazywane do rąk czytelnika albo
wysyłane na drukarkę sieciową.
21.Omów i podaj przykłady wymagań
funkcjonalnych dla systemu informatycznego.
Wymagania funkcjonalne:
Opisują funkcje (czynności, operacje) wykonywane
przez system.
Funkcje te mogą być również wykonywane przy użyciu
systemów zewnętrznych.
Określenie wymagań funkcjonalnych obejmuje
następujące kwestie:
Określenie wszystkich rodzajów użytkowników, którzy
będą korzystać z systemu.
Określenie wszystkich rodzajów użytkowników, którzy
są niezbędni do działania systemu (obsługa,
wprowadzanie danych, administracja).
Dla każdego rodzaju użytkownika określenie funkcji
systemu oraz sposobów korzystania z planowanego
systemu.
Określenie systemów zewnętrznych (obcych baz danych,
sieci, Internetu), które będą wykorzystywane podczas
działania systemu.
Ustalenie struktur organizacyjnych, przepisów prawnych,
statutów, zarządzeń, instrukcji, itd., które pośrednio lub
bezpośrednio
określają funkcje wykonywane przez planowany system.
22.Omów i podaj przykłady wymagań
niefunkcjonalnych dla systemu informatycznego.
Wymagania niefunkcjonalne:
Opisują ograniczenia, przy których system ma realizować
swoje funkcje.
Wymagania dotyczące produktu.
Np. musi istnieć możliwość operowania z systemem
wyłącznie za pomocą klawiatury.
Wymagania dotyczące procesu.
Np. proces realizacji harmonogramowania zleceń musi
być zgodny ze standardem opisanym w dokumencie
XXXA/96.
Wymagania zewnętrzne.
Np. system harmonogramowania musi współpracować z
bazą danych systemu komputerowego działu marketingu
opisaną w dokumencie YYYB/95.
Niedopuszczalne są jakiekolwiek zmiany w strukturze tej
bazy.
Są to np: wymagania jakościowe (określają szczegółowe
oczekiwania co do wydajności), technologiczne,
bezpieczeństwa
Mogą definiować ograniczenia systemu, takie jak
możliwości urządzeń wejścia-wyjścia i reprezentacje
danych używane przez interfejsy systemu.
Wymagania niefunkcjonalne wynikają z:
potrzeb użytkownika,
ograniczeń budżetowych,
strategii firmy,
konieczności współpracy z innymi systemami sprzętu lub
oprogramowania,
czynników zewnętrznych.
23.Omów metody specyfikacji wymagań dla systemów
informatycznych.
Metody specyfikacji wymagań:
Język naturalny - najczęściej stosowany. Wady:
niejednoznaczność powodująca różne rozumienie tego
samego tekstu; elastyczność, powodująca wyrazić te same
treści na wiele sposobów. Utrudnia to wykrycie
powiązanych wymagań i powoduje trudności w wykryciu
sprzeczności.
Formalizm matematyczny. Stosuje się rzadko (dla
specyficznych celów).
Język naturalny strukturalny. Język naturalny z
ograniczonym słownictwem i składnią. Tematy i
zagadnienia wyspecyfikowane w punktach i podpunktach.
Tablice, formularze. Wyspecyfikowanie wymagań w
postaci (zwykle dwuwymiarowych) tablic, kojarzących
różne aspekty (np. tablica ustalająca zależność pomiędzy
typem użytkownika i rodzajem usługi).
Diagramy blokowe: forma graficzna pokazująca cykl
przetwarzania.
Diagramy kontekstowe: ukazują system w postaci
jednego bloku oraz jego powiązania z otoczeniem,
wejściem i wyjściem.
Diagramy przypadków użycia: poglądowy sposób
przedstawienia aktorów i funkcji systemu.
24.Omów przykładowy zakres treści dokumentu
opisującego wymagania na system
informatyczny.
Streszczenie (maksymalnie 200 słów)
Spis treści
Status dokumentu (autorzy, firmy, daty, podpisy, itd.)
Zmiany w stosunku do wersji poprzedniej
1. Wstęp
1.1. Cel
1.2. Zakres
1.3. Definicje, akronimy i skróty
1.4. Referencje, odsyłacze do innych dokumentów
1.5. Krótki przegląd
2. Ogólny opis
2.1. Walory użytkowe i przydatność projektowanego
systemu
2.2. Ogólne możliwości projektowanego systemu
2.3. Ogólne ograniczenia
2.4. Charakterystyka użytkowników
2.5. Środowisko operacyjne
2.6. Założenia i zależności
3. Specyficzne wymagania
3.1. Wymagania funkcjonalne (funkcje systemu)
3.2. Wymagania niefunkcjonalne (ograniczenia).
Dodatki
Kolejność i numeracja punktów w przedstawionym
spisie treści powinna być zachowana. W przypadku
gdy pewien punkt nie zawiera żadnej informacji
należy wyraźnie to zasygnalizować przez
umieszczenie napisu „Nie dotyczy”.
Dla każdego wymagania powinien być podany
powód jego wprowadzenia: cele przedsięwzięcia,
których osiągnięcie jest uwarunkowane danym
wymaganiem.
Wszelki materiał nie mieszczący się w podanych
punktach należy umieszczać w dodatkach.
Często spotykane dodatki:
Wymagania sprzętowe.
Wymagania dotyczące bazy danych.
Model (architektura) systemu.
Słownik terminów (użyte terminy, akronimy i skróty
z wyjaśnieniem)
Indeks pomocny w wyszukiwaniu w dokumencie
konkretnych informacji (dla dokumentów dłuższych
niż 80 stron)
25.Omów zakres fazy analizy w cyklu
wytwórczym systemów informatycznych.
Celem fazy analizy jest ustalenie wszystkich tych
czynników lub warunków w dziedzinie
przedmiotowej, w otoczeniu realizatorów projektu,
w istniejących lub planowanych systemach
komputerowych, które mogą wpłynąć na decyzje
projektowe, na przebieg procesu projektowego i na
realizację wymagań. Wynikiem jest logiczny model
systemu, opisujący sposób realizacji przez system
postawionych wymagań, lecz abstrahujących od
szczegółów implementacyjnych.
Czynności wykonywane w tej fazie:
Rozpoznanie, wyjaśnianie, modelowanie,
specyfikowanie i dokumentowanie rzeczywistości
lub problemu będącego przedmiotem projektu;
Ustalenie kontekstu projektu;
Ustalenie wymagań użytkowników;
Ustalenie wymagań organizacyjnych
Inne ustalenia, np. dotyczące preferencji
sprzętowych, preferencji w zakresie
oprogramowania, ograniczeń finansowych,
ograniczeń czasowych, itd.
26.Omów główne cechy modelu analitycznego i
podstawowe czynności w fazie analizy systemu
informatycznego.
Cechy modelu analitycznego (logicznego):
-Uproszczony opis systemu;
-Hierarchiczna dekompozycja funkcji systemu;
-Model logiczny jest opisany przy pomocy notacji
zgodnej z pewną konwencją;
-Jest on zbudowany przy użyciu dobrze
rozpoznanych metod i narzędzi;
-Jest on używany do wnioskowania o przyszłym
oprogramowaniu;
-Model oprogramowania powinien być jego
uproszonym opisem, opisującym wszystkie istotne
cechy oprogramowania na wysokim poziomie
abstrakcji.
-Model ten jednakże nie zastępuje doświadczenia i
wnikliwości projektantów, lecz pomaga
projektantom w zastosowaniu tych walorów.
Logiczny model oprogramowania:
• pokazuje co system musi robić;
• jest zorganizowany hierarchicznie, wg poziomów
abstrakcji
• unika terminologii implementacyjnej
• pozwala na wnioskowanie „od przyczyny do
skutku” i odwrotnie.
Czynności w fazie analizy:
-Rozpoznanie, wyjaśnianie, modelowanie,
specyfikowanie i dokumentowanie rzeczywistości lub
problemu będącego przedmiotem projektu;
-Ustalenie kontekstu projektu;
-Ustalenie wymagań użytkowników;
-Ustalenie wymagań organizacyjnych
-Inne ustalenia, np. dotyczące preferencji sprzętowych,
preferencji w zakresie oprogramowania, ograniczeń
finansowych, ograniczeń czasowych, itd.
27. Omów przykłady nieobiektowego podejścia do
analizy, projektu i implementacji systemów
informatycznych.
Analiza:
Głównym celem analizy jest wprowadzenie
strukturalnej specyfikacji opisu projektu za pomocą
narzędzi modelowania:
– diagramów przepływu danych — DFD,
– diagramów obiekt-relacja-atrybut — ERD,
– diagramów przejść stanów — STD;
Wynikiem analizy jest zbudowanie następujących
modeli:
– model otoczenia,
– model zachowania systemu;
Modele są opisem formalnym systemu, niezależnym od
technologii, jakiej użyje się do implementacji nowego
systemu;
Na końcu etapu analizy określa się dokładniej niż w
poprzednim etapie budżet projektu oraz kalkulację
kosztów i zysków;
Projektowanie:
Polega na:
– wyodrębnienie tych części modelu zachowania
systemu, które będą implementowane w systemie
informatycznym;
– przydzielenie poszczególnych części specyfikacji do
odpowiednich procesorów lub serwerów (przetwarzanie
rozproszone); fragmenty DFD (te, które będą
implementowane) są mapowane na zadania;
– zaprojektowanie struktury hierarchii modułów
wewnątrz danego zadania;
– transformacja diagramów ERD na relacyjną bazę
danych (projektowanie logiczne danych);
Implementacja:
W fazie implementacji:
– realizowane jest kodowanie i integracja modułów;
– stosuje się techniki programowania strukturalnego
oraz implementacji top-down;
28.Omów przykłady obiektowego podejścia do
analizy, projektu i implementacji systemów
informatycznych.
Analiza obiektowa
– opracowanie modelu obiektowego dziedziny
zastosowania;
– rozpoznane obiekty odzwierciedlają byty i operacje
związane z rozwiązywanym problemem;
Projektowanie obiektowe
– opracowanie modelu obiektowego systemu
oprogramowania, który będzie implementacją
zidentyfikowanych wymagań;
– obiekty projektu obiektowego są związane z
rozwiązaniem problemu;
Zadania w etapach fazy projektowania:
– uściślenie istniejących definicji klas, np. metod,
– dziedziczenie klas i operacji,
– szczegółowy projekt operacji wraz z
przeprojektowaniem ich algorytmów,
– wprowadzenie ogólnych mechanizmów realizacji
dynamiki obiektów,
– decyzje o trwałości obiektów,
– modularyzacja i ukrywanie informacji,
– optymalizacja modelu,
– dokumentacja projektu;
Programowanie obiektowe
– realizacja projektu oprogramowania za pomocą
języka programowania obiektowego;
– języki obiektowe umożliwiają bezpośrednią
implementację obiektów i dostarczają udogodnienia do
definiowania klas obiektów;
29. Co to jest system informatyczny i jakie są jego
główne wyznaczniki jakości.
System informatyczny to złożony program
komputerowy lub zespół współdziałających ze sobą
programów, przeznaczonych do wykonywania
określonych funkcji: np. system operacyjny, system
zarządzania bazami danych .
Najczęściej o systemie informatycznym mówi się wtedy,
gdy do zbierania, gromadzenia, przesyłania i
przetwarzania danych zastosowane są techniczne środki
informatyki, a przynajmniej komputer do przetwarzania.
Zestaw technicznych środków informatyki jest
przeznaczony do realizacji zadań określonych przez
system informacyjny .
Podsumowując – system informatyczny to określony
obszar systemu informacyjnego danego obiektu,
obsługiwany za pomocą technicznych środków
dostępnych w informatyce.
Wyznaczniki jakości systemu informatycznego:
zgodny z wymaganiami użytkownika
-niezawodny
-efektywny
-łatwy w konserwacji
-interoperacyjny (jeżeli nie jest autonomiczny)
-ergonomiczny
30. Omów podstawowe diagramy statyczne w języku
IBM/Rational UML.
Diagram klas – to statyczny diagram strukturalny,
przedstawiający strukturę systemu w modelach
obiektowych przez ilustrację struktury klas i zależności
między nimi. Elementami występującymi w diagramie
klas są:
-klasy
-interfejsy
-grupy współdziałania
Pomiędzy elementami występującymi na diagramie klas
występują związki:
-zależności
-generalizacji
-asocjacji
-agregacji
Diagram klas jest najczęściej wykorzystywanym
diagramem w notacji UML.
Diagram obiektów - zamiast klas pokazują instancje.
Przydają się do wyjaśniania drobnych elementów ze
skomplikowanymi relacjami, zwłaszcza
rekurencyjnymi.Każdy prostokąt na diagramie obiektów
odpowiada pojedynczej instancji. Nazwy instancji na
diagramach UML są podkreślone. Nazwy klas lub
instancji mogą zostać pominięte na diagramach obiektów,
pod warunkiem, że sens diagramu pozostaje jasny.
Diagram komponentów - (zwany także diagramem
implementacji) to diagram przedstawiający jeden z
aspektów modelu zgodnego z UML. Przedstawia fizyczne
elementy wchodzące w skład systemu i połączenia między
nimi.
Diagram pakietów – to diagram służący do
porządkowania struktury systemu. Stosowane, aby
uprościć skomplikowane diagramy klas, klasy grupujemy
w pakiety. Pakiet to zbiór logicznie powiązanych
elementów UML.
Pakiety to prostokąty z małymi zakładkami na górze.
Nazwa pakietu znajduje się na zakładce albo wewnątrz
prostokąta. Strzałki z przerywanymi liniami to zależności.
Jeden pakiet jest zależny od drugiego, jeśli zmiany w
drugim pakiecie mogą wymusić zmiany w pierwszym.
Diagram wdrożenia - (Deployment Diagram) obrazuje
konfigurację węzłów działających w czasie wykonania i
zainstalowane na nich komponenty. Odnosi się do
statycznych aspektów perspektywy wdrożeniowej. Wiąże
się z diagramem komponentów, ponieważ zwykle każdy
węzeł zawiera co najmniej 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 - opisuje, co robi system z
punktu widzenia zewnętrznego obserwatora. Eksponują to,
co robi system, a nie jak to robi. Diagramy przypadków
użycia pozostają w bliskim związku ze scenariuszami.
Przypadek użycia to podsumowanie scenariuszy
pojedynczego zadania lub celu. Aktor to ktoś albo
coś, co inicjuje zdarzenia związane z tym zadaniem.
Aktor po prostu określa rolę, którą odgrywa
człowiek lub obiekt.
Jeden przypadek użycia może mieć wielu aktorów.
Diagramy przypadków użycia mają trzy
zastosowania:
-Określanie funkcji (wymagań). Nowe przypadki
użycia często generują nowe wymagania, kiedy
system jest analizowany i projekt przybiera coraz
wyraźniejszy kształt.
-Komunikacja z klientami. Prostota notacji sprawia,
że diagramy przypadków użycia są dobrym
sposobem porozumiewania się programistów z
klientami.
-Generowanie przypadków testowych. Zbiór
scenariuszy danego przypadku użycia może
zasugerować sposoby testowania tych scenariuszy.
Diagram stanów -Obiekty cechują się
zachowaniami i stanem. Stan obiektu zależy od jego
bieżącej aktywności lub warunków. Diagram stanów
pokazuje możliwe stany obiektu oraz przejścia, które
powodują zmianę stanu. Stany to zaokrąglone
prostokąty. Przejścia to strzałki wiodące od jednego
stanu do drugiego. Zdarzenia lub warunki
wyzwalające przejścia są zapisane obok strzałek.
Diagram czynności (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 (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) - 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 - to narzędzie do
przedstawiania złożonych zależności miedzy
przyczynami i skutkami. Diagramy zależności
pozwalają odnaleźć często trudną do wykrycia
zależność problemu od pierwotnej przyczyny.
Pomagają zilustrować łańcuchy zależności i
wzajemnych zależności, przez co ułatwiają podjęcie
działania w odpowiednim miejscu. Pomagają
również w identyfikacji efektów ubocznych tych
działań.
Diagram przepływu danych - (DFD – Data Flow
Diagram) jest graficzną prezentacją przepływu
danych w procesie. Na proces składają się
następujące elementy:
-Funkcje — (procesy) realizują określone cele; jeśli
funkcji nie można rozbić na pod-funkcje, wówczas
nosi ona nazwę elementarnej.
-Magazyny danych — trwałe lub tymczasowe składnice
danych, które są argumentami dla funkcji.
-Terminatory — obiekty, które nie są częścią systemu,
ale stanowią odbiorców bądź źródła danych lub
argumentów funkcji.
Przepływy — elementy pokazujące kierunek przesyłu
danych (np. bajtów, znaków, pakietów..).
Diagram przepływu danych obrazuje za pomocą
przepływów kierunek przepływu danych pomiędzy
funkcjami, magazynami i obiektami zewnętrznymi.
33.Porównaj następujące podejścia do analizy i
projektowania systemów informatycznych: 1)
podejście: encja-związek, 2) podejście obiektowe.
Model encja-związek reprezentuje dane i związki
pomiędzy nimi. Podejście to pozwala na odwzorowanie
w systemie danych i powiązań pomiędzy nimi. Pozwala
na analizę rodzajów danych, ich przepływu w
procesach przetwarzania, oraz na odpowiednie
zaprojektowanie przechowywania danych. Jest to
podejście dobre dla systemów, których głównym
zadaniem jest przetwarzanie danych i ich
przedstawianie, a także przechowywanie. Korzystne dla
systemów bazodanowych.
Model obiektowy skupia się bardziej nad tym jak dane
są przetwarzane, jaki jest do nich dostęp, jaka jest
wymiana danych pomiędzy obiektami. W modelu
obiektowym na drugi plan przesunięte jest jak dane są
przechowywane, a także jak są reprezentowane.
Znacznie istotniejsze jest kto ma do nich dostęp, jakie
obiekty biorą udział w ich przetwarzaniu i jakie metody
operują na danych. Podejście to jest korzystne dla
wszystkich systemów, gdzie konieczna jest
odpowiednia kontrola dostępu do danych, poprawności
danych, oraz kontrola sposobu przetwarzania.
34.Omów zagadnienie audytu w procesie
wytwórczym systemów informatycznych.
Audytem nazywany jest niezależny przegląd i ocenę
jakości oprogramowania, która zapewnia zgodność z
wymaganiami na
oprogramowanie, a także ze specyfikacją, generalnymi
założeniami, standardami, procedurami, instrukcjami,
kodami oraz kontraktowymi i licencyjnymi
wymaganiami.
Aby zapewnić obiektywność, audyt powinien być
przeprowadzony przez osoby niezależne od zespołu
projektowego.
Audyt powinien być przeprowadzany przez
odpowiednią organizację audytu (która aktualnie
formuje się w Polsce, Polskie Stowarzyszenie Audytu)
lub przez osoby posiadające uprawnienia/licencję
audytorów.
Reguły i zasady audytu są określone w normie:
ANSI/IEEE Std 1028-1988 „IEEE Standard for
Reviews and Audits”.
Celem Audytu jest dostarczenie odbiorcy i dostawcy
obiektywnych, aktualnych i syntetycznych informacji o
stanie projektu. Zebrane informacje służą jako
podstawa do podejmowania strategicznych decyzji w
projekcie
Przedmioty:
- procesy projektu informatycznego - ma to na celu
sprawdzenie, czy wykonane prace oraz sposób ich
wykonania są prawidłowe
- produkty projektu informatycznego - ma to na celu
sprawdzenie czy rezultaty poszczególnych prac
odpowiadają zakładanym wymaganiom.
Perspektywy:
- technologia - ma na celu sprawdzenie, czy użyte
techniki oraz opracowane rozwiązania są prawidłowe i
prawidłowo stosowane
- zarządzanie - ma to na celu sprawdzenie, czy sposób
zarządzania projektem umożliwia jego sukces
35.Omów zagadnienie inspekcji oprogramowania w
procesie wytwórczym systemów informatycznych.
Inspekcja to formalna technika oceny, w której
wymagania na oprogramowanie, projekt lub kod są
szczegółowo badane przez osobę lub grupę osób nie
będących autorami, w celu identyfikacji błędów,
naruszenia standardów i innych problemów [IEEE Std.
729-1983]
- Inspekcje stosowane są dla "elitarnych" systemów, czyli
takich, które spełniać mają bardzo ważne zadania.
- nie jest prosta analiza kosztów inspekcji,
- nie ma gotowych narzędzi programowych - wymagane
jest doświadczenie ludzi.
Korzyści z inspekcji:
- wzrost produktywności
- skrócenie czasu projektu
- zmniejszenie kosztu i skrócenie czasu wykonania testów
(mniej testów regresyjnych)
- 10x mniejsze koszty pielęgnacji
- poprawa procesu programowego
- większy komfort pracy
- mniejsze koszty marketingu
Inspekcje przeprowadzane są przez specjalistów dla
specjalistów bez udziału kierownictwa. Przykładowo
inspekcje modułów są przeprowadzane przez pracujące
równolegle podgrupy projektowe.
36.Omów rodzaje testów oprogramowania w
odniesieniu do cyklu życia systemu informatycznego.
badanie prognostyczne - zanim powstanie kod źródłowy,
czyli w fazach: określenia wymagań i projektowania
Zalety:
- Zwiększenie prawdopodobieństwa uniknięcia lub
zmniejszenia oddziaływania zjawiska propagacji błędów,
- Stosunkowo niskie koszty testowania,
- Możliwość przebadania wielu różnych projektów
oprogramowania w celu wyboru najlepszego do
implementacji
Wady:
- Bazowanie na modelu oprogramowania, co może
zmniejszyc dokładność badania (potencjalna rozbieżność z
właściwościami implemetacyjnymi
badania diagnostyczne:
Typy:
- Analiza dynamiczna
- analiza statyczna
- inspekcje
- audyty
37. Omów uwarunkowania prawne i inżynierskie
procesu testów akceptacyjnych systemu
informatycznego.
Na podstawie art. 21 ust. 6 ustawy z dnia 17 lutego
2005 r. o informatyzacji działalności podmiotów
realizujących zadania publiczne (Dz. U. Nr 64, poz. 565)
zarządza się, co następuje:
§ 1. Rozporządzenie określa:
1) metodykę , warunki i tryb sporządzania testów
akceptacyjnych;
2) sposób postępowania w zakresie badania, o którym
mowa w art. 21 ust. 1 ustawy z dnia 17 lutego 2005 r. o
informatyzacji działalności podmiotów realizujących
zadania publiczne, zwanego dalej „badaniem”, w tym
sposób dokumentowania wyników badania oraz
weryfikacji badania;
§ 3. 1. Podmiot publiczny sporządza testy akceptacyjne z
zachowaniem metodyki prowadzenia projektów
informatycznych o publicznym zastosowaniu
odpowiadającej specyfice systemu teleinformatycznego
używanego do realizacji zadań publicznych, w zakresie
obejmującym wyłącznie funkcjonalność oprogramowania
testowanego.
2. Sporządzenie testu akceptacyjnego obejmuje
przygotowanie:
1) specyfikacji przypadku testowego, zgodnie z wzorem
określonym w załączniku nr 1 do rozporządzenia;
2) specyfikacji scenariusza testowego, zgodnie z wzorem
określonym w załączniku nr 2 do rozporządzenia, jeżeli jej
sporządzenie jest niezbędne do przeprowadzenia badania z
uwagi na funkcjonalność oprogramowania testowanego.
§ 4. 1. Podmiot publiczny, mając na uwadze, aby badanie
obejmowało w pełni funkcjonalność oprogramowania
testowanego:
1) sporządza opis badania składający się z:
a) specyfikacji poszczególnych przypadków
testowych,
b) specyfikacji poszczególnych scenariuszy
testowych w przypadku, o którym mowa w § 3 ust. 2
pkt 2;
2) zapewnia, nieodpłatnie dla podmiotów
uprawnionych, dostęp do oprogramowania
testowego albo, zgodnie z § 5 ust. 2, do
oprogramowania komunikacyjnego;
3) publikuje, w Biuletynie Informacji Publicznej,
opis badania, o którym mowa w pkt 1, oraz
informacje niezbędne dla uzyskania skutecznego
dostępu przez podmioty uprawnione do
oprogramowania, o którym mowa w pkt 2.
38. Omów istotę testowania metodą black box i
white box.
White box
Testowanie n/z białej skrzynki pozwala sprawdzić
wewnętrzną logikę programów poprzez odpowiedni
dobór danych wejściowych, dzięki czemu można
prześledzić wszystkie ścieżki przebiegu sterowania
programu.
Tradycyjnie programiści wstawiają kod
diagnostyczny do programu aby śledzić wewnętrzne
przetwarzanie. Debuggery pozwalają programistom
obserwować wykonanie programu krok po kroku.
Często niezbędne staje się wcześniejsze
przygotowanie danych testowych lub specjalnych
programów usprawniających testowanie (np.
programu wywołującego testowaną procedurę z
różnymi parametrami).
Dane testowe powinny być dobrane w taki sposób,
aby każda ścieżka w programie była co najmniej raz
przetestowana.
Ograniczeniem testowania na zasadzie białej
skrzynki jest niemożliwość pokazania brakujących
funkcji w programie. Wadę tę usuwa testowanie n/z
czarnej skrzynki.
Black box
Tak określa się sprawdzanie funkcji
oprogramowania bez zaglądania do środka
programu. Testujący traktuje sprawdzany moduł jak
„czarną skrzynkę”, której wnętrze jest niewidoczne.
Testowanie n/z czarnej skrzynki powinno
obejmować cały zakres danych wejściowych.
Testujący powinni podzielić dane wejściowe w
„klasy równoważności”, co do których istnieje duże
przypuszczenie, że będą produkować te same błędy.
Np. jeżeli testujemy wartość „Malinowski”, to
prawdopodobnie w tej samej klasie równoważności
jest wartość „Kowalski”. Celem jest uniknięcie
efektu „eksplozji danych testowych”.
„Klasy równoważności” mogą być również zależne
od wyników zwracanych przez testowane funkcje.
Np. jeżeli wejściem jest wiek pracownika i istnieje
funkcja zwracająca wartości „młodociany”,
„normalny” „wiek emerytalny”, wówczas implikuje
to odpowiednie klasy równoważności dla danych
wejściowych.
Wiele wejść dla danych (wiele parametrów funkcji)
może wymagać zastosowania pewnych
systematycznych metod określania ich kombinacji,
np. tablic decyzyjnych lub grafów przyczyna-skutek.
39. Omów zagadnienie architektury systemów
informatycznych.
- Architektura globalna: koordynacja i komunikacja
pomiędzy organizacjami;
- Architektura korporacyjna (enterprise):
koordynacja i komunikacja w obrębie organizacji;
- Architektura systemu: koordynacja i komunikacja
pomiędzy aplikacjami;
- Architektura aplikacji (Subsystem): dostarczanie
funkcjonalności;
- Makro-architektura (Frameworks): powtarzające
się aplikacje;
- Mikro-architektura: wzorce projektowe;
- Obiekty: specyficzne konstrukcje w językach
programowania;
40. Omów zagadnienie projektowania
architektonicznego systemów informatycznych.
Wzorce architektoniczne
1.Konstrukcyjne:
- Służą do pozyskiwania obiektów;
- Opisują szczegółowo, jak obiekt może zostać
stworzony,
- Czynią kod niezależnym od typów tworzonych
obiektów;
- Wybór konkretnej klasy uzależniany jest np. od
parametrów konfiguracyjnych;
- Przykłady:
+ Singleton,
+ Fabryka,
+ Metoda Fabrykująca,
+ Fabryka Abstrakcyjna,
+ Budowniczy,
+ Prototyp;
2.Strukturalne:
- Stosowany do łączenia obiektów w większe struktury;
- Zastosowanie np. w implementacji złożonego
interfejsu użytkownika;
- Przykłady:
+ Fasada,
+ Adapter,
+ Most,
+ Kompozyt,
+ Dekorator,
+ Waga Piórkowa,
+ Proxy;
3.Operacyjne:
- W celu definiowania komunikacji pomiędzy
obiektami;
- Pomagają kontrolować przepływ danych w złożonym
programie;
- Przykłady:
+ Iterator,
+ Łańcuch Odpowiedzialności,
+ Stan,
+ Mediator,
+ Obserwator,
+ Strategia;
41. Omów istotę koncepcji wzorców projektowych w
projektowaniu systemów informatycznych.
Wzorce projektowe stanowią powtarzalne rozwiązanie
zagadnień projektowych, z którymi się wciąż
spotykamy;
- Wzorce dostarczają sprawdzonych rozwiązań dla
powtarzających się problemów;
- Możliwe do zastosowania w wielu rzeczywistych
kontekstach;
- Wpływają na sposób modelowania;
- Zapobiegają „wymyślaniu koła od nowa”;
- Usprawniają komunikację
- Ułatwiają tworzenie dokumentacji
42. Omów wzorzec projektowy …… (nazwa jednego
z wzorców z wykładu).
- konstrukcyjne
--- służą do pozyskiwania obiektów;
--- opisują szczegółowo, jak obiekt może zostać
stworzony,
--- czynią kod niezależnym od typów tworzonych
obiektów;
--- wybór konkretnej klasy uzależniany jest np. od
parametrów konfiguracyjnych;
- strukturalne
--- stosowany do łączenia obiektów w większe
struktury;
--- zastosowanie np. w implementacji złożonego
interfejsu użytkownika
- operacyjne (czynnościowe)
--- definiowanie komunikacji pomiędzy obiektami;
--- kontrolowanie przepływów danych w złożonych
algorytmach (programach);
--- przydział zobowiązań obiektom;
43. Omów model niezawodności oprogramowania
według Jelińskiego-Morandy (1972).
- Wykrywanie błędów jest niezależne;
- Usuwanie wykrytych błędów nie generuje nowych;
- Intensywność wykrywania błędów - proporcjonalna
do liczby błędów pozostających w oprogramowaniu:
(nie dałem rady przenieść tego wzoru)
44.Omów zjawisko propagacji kosztów błędu
oprogramowania i podaj przykładowe szacunki
kosztów.
Wyniki badań przeprowadzonych przez Boehma w
latach osiemdziesiątych jak i obecnie prowadzone
badania potwierdzają, że koszt poprawy błędu rośnie
wykładniczo w zależności od etapu wytwarzania
oprogramowania. Najmniej kosztuje poprawa na etapie
analizy, najwięcej po wdrożeniu systemu do produkcji.
Jeśliby błąd związany z rokiem 2000 usunąć na etapie
implementacji to koszt z tym związany byłby tysiąckrotnie
niższy w stosunku do kosztu związanego z jego poprawą
po wdrożeniu systemu.
W większości procesów wytwarzania testowanie systemu
jest wykonywane na samym końcu. Oznacza to, że jest
ono szczególnie narażone na przekroczenie kosztów i
harmonogramu, co oznacza po prostu, że czas potrzebny
na testowanie jest obcinany, ponieważ wcześniejsze fazy
przekroczyły termin i budżet.
Szacunki kosztów wg Roger’a Pressman’a (1997):
--- Testowanie: ~ 30 % - 40 % całkowitej
pracochłonności;
--- Testowanie systemów krytycznych: 70% - 80%
całkowitej pracochłonności (!);
Dodatkowo należy brać pod uwagę tzw. koszty utraconych
korzyści
45.Omów źródła kosztów nieprawidłowości
oprogramowania.
Oprogramowanie zawierające błędy, może być źróbłem
kosztów. Koszt wykrycia i naprawienia błędu często
przekrocza koszt napisania fragmentu kodu od nowa. Do
kosztów oprogramowania złej jakości zaliczamy:
1) Koszty jakości w skład których wchodzą:
-koszty błędów (traktowane jako straty),
-koszty oceny (traktowane jako nakłady),
-koszty zapobiegania (traktowane jako nakłady).
2) Koszty procesu:
-koszty niezgodności (traktowane jako straty),
-koszty zgodności (traktowane jako nakłady).
3) Straty jakości (skutki odchyleń od wymagań
jakościowych)
Program złej jakości może mieć również potencjalnie duże
koszty błędnych wykonań co może narazić na wysokie
straty finansowe instytucji korzystającej z błędnie
działającego oprogramowania. Oprogramowanie dobrej
jakości to mniejsze koszty pielęgnacji (naprawczej) oraz
mniejsze koszty marketingu który ma na celu ukrywanie
braku jakości
46.Co to jest testowanie, weryfikacja i walidacja
oprogramowania? Podaj przykłady.
Testowanie oprogramowania - proces związany z
wytwarzaniem oprogramowania. Jest jednym z procesów
kontroli jakości oprogramowania. Testowanie
oprogramowania jest jednym z kluczowych etapów
procesu zapewnienia jego jakości. Celem testowania
oprogramowania jest sprawdzanie jak dobry jest docelowy
produkt oraz sprawdzenie czy oprogramowanie spełni
swoje zadanie. Wśród testów wyróżniamy testy
dynamiczne, które polegają na wykonywaniu
(fragmentów) programu albo modeli symulacyjnych i
porównywaniu uzyskanych wyników z wynikami
poprawnym oraz testy statyczne, oparte na analizie kodu
albo modeli analitycznych lub projektowych .Testowaniu
oprogramowania podlega: wsydajność systemu, interfejsy
systemu, własności operacyjne systemu, testy zużycia
zasobów oraz zabezpieczenie systemu
Weryfikacja - testowanie zgodności systemu z
wymaganiami zdefiniowanymi w fazie określenia
wymagań. Proces weryfikacji oprogramowania można
określić jako poszukiwanie i usuwanie błędów na
podstawie obserwacji błędnych wykonań oraz innych
testów. Weryfikacja uwzględnia następujące czynności:
przeglądy techniczne oraz inspekcje oprogramowania;
sprawdzanie czy wymagania na oprogramowanie są
zgodne z wymaganiami użytkownika; sprawdzanie czy
komponenty projektu są zgodne z wymaganiami na
oprogramowanie; testowanie jednostek oprogramowania
(modułów); testowanie integracji oprogramowania,
testowanie systemu; testowanie akceptacji systemu przez
użytkowników
Walidacja (atestowanie)- ocena systemu lub komponentu
podczas lub na końcu procesu jego rozwoju na zgodności
z wyspecyfikowanymi wymaganiami. Atestowanie jest
więc weryfikacją końcową. Walidacja sprawdza, czy
oprogramowanie jest zgodne z oczekiwaniami
użytkownika.
47.Omów istotę i przykłady metod
prognostycznego badania jakości
oprogramowania.
Badanie prognostyczne przeprowadzane są wtedy
gdy nie ma kodu źródłowego.
Głównymi zaletami podejścia prognostycznego jest:
Zwiększenie prawdopodobieństwa uniknięcia lub
zmniejszenia oddziaływania zjawiska propagacji
błędów; stosunkowo niskie koszty testowania oraz
możliwość przebadania wielu różnych projektów
oprogramowania w celu wyboru najlepszego do
implementacji. Wadą podejścia prognostycznego jest
bazowanie na modelu oprogramowania, co może
zmniejszyć dokładność badania (potencjalna
rozbieżność z właściwościami implementacyjnymi).
Metody prognostyczne bazują na: metodach
specyfikacji formalnej programów; badaniu logiki
sterowania programów oraz na metrykach projektu
oprogramowania. Wyróżniamy dwa
komplementarne podejścia: badanie właściwości
statycznych oraz badanie właściwości dynamicznych
48.Omów istotę i przykłady metod
diagnostycznego badania jakości
oprogramowania.
Badanie diagnostyczne przeprowadzane są gdy
istnieje kod źródłowy. W skład diagnostycznego
badania oprogramowania wchodzi analiza
dynamiczna czyli eksperymentowanie z działającym
kodem programu oraz analiza statyczna czyli praca z
kodem źródłowym w celu rozpoznania
funkcjonalności testowanego kodu oraz
zaprojektowania odpowiednich testów. Do Testów
diagnostycznych zalicza się testy strukturalne (testy
białej skrzynki), które opracowuje się na podstawie
wiedzy i implementacji oprogramowania. Stosuje się
je do stosunkowo niewielkich jednostek programów,
takich jak podprogramy i operacje związane z
obiektem. Podczas testów strukturalnych tester może
analizować kod i korzystać z wiedzy o strukturze
komponentu przy opracowywaniu danych testowych.
Drugim rodzajem testów diagnostycznych jest
Testowanie strategią czarnej skrzynki. Polega ono na
sprawdzaniu funkcji oprogramowania bez zaglądania
do środka programu. Testujący traktuje sprawdzany
moduł jak „czarną skrzynkę”, której wnętrze jest
niewidoczne. Testowanie metodą czarnej skrzynki
powinno obejmować cały zakres danych
wejściowych. Tester zadaje dane wejściowe i
analizuje dane wyjściowe. Jeżeli dane wyjściowe
(wyniki) nie są zgodne z założeniami, to test
pozytywnie wykrył defekt oprogramowania.
49. Wymień i omów składowe jakości
oprogramowania na drugim poziomie drzewa
jakości.
Użyteczność - dostępność oczekiwanych usług
Niezawodność – np. prawdopodobieństwo błędu w
czasie realizacji transakcji, średni czas pomiędzy
błędnymi wykonaniami, dostępność (procent czasu,
w którym system jest dostępny), czas restartu po
awarii systemu, prawdopodobieństwo zniszczenia
danych w przypadku awarii.
Efektywność
Wielokrotne użycie – ponowne wykorzystanie
gotowych elementów
Pielęgnacyjność – podatność na pielęgnowanie,
łatwość wprowadzania zmian
Przenośność – np. procent kodu zależnego od
platformy docelowej, liczba platform docelowych,
koszt przeniesienia na nową platformę.
Testowalność – podatność na testowanie
50. Omów główne klasy błędów w systemach
informatycznych
Klasyfikacja błędów:
- funkcjonalne - funkcja źle wykonana bądź źle
funkcjonująca
- systemowe - nieprawidłowe zarządzanie zasobami,
mylne interfejsy, zła komunikacja z bazą danych
bądź jej brak
- przetwarzania - niewłaściwe przetwarzanie danych w
poszczególnych modułach
- danych - źle wprowadzone dane, ich brak, błędna
specyfikacja
- graficzne - interfejs graficzny niezgodny z
założeniami
- kodowania - niewłaściwe użycie języka
programowania
- dokumentacji - niepełna lub błędna dokumentacja
- inne - niezidentyfikowana przyczyna wystąpienia
51. Omów czynności procesu testowania
oprogramowania.
Fazy procesu testowania:
- testowanie komponentów (jednostek) - testuje się
poszczególne komponenty, aby zapewnić, że działają
poprawnie,
- testowanie modułów - moduł jest kolekcją
niezależnych komponentów takich jak klasy obiektów,
abstrakcyjne typy danych, albo bardziej luźną kolekcją
procedur i funkcji,
- testowanie podsystemów - ta faza obejmuje
testowanie kolekcji modułów, które zintegrowano w
podsystemie,
- testowanie systemu - ten proces testowania ma
wykryć błędy wynikające z nieprzewidzianych
interakcji między zintegrowanymi podsystemami i
problemów z interfejsami podsystemów,
- testowanie odbiorcze - jest to końcowa faza procesu
testowania przed przyjęciem systemu do użytkowania.
52. Co to jest przypadek testowy, scenariusz testów?
Podaj przykłady.
Scenariusz testów:
- dokument opisujący procedury i przypadki testowe
dla określonego produktu
- jest podstawą pracy testera z danym produktem
- obejmuje:
--- listę testowanych produktów
--- odwołania do wymagań
--- przypadki testowe
--- kryteria poprawności
--- listę agentów testowych
--- szczegółowe procedury testowania dla produktów
Przypadek testowy:
- ściśle określona ścieżka przejścia przez testowany
produkt lub charakterystyczna klasa danych
wejściowych
- określa szczegółowy zakres w testowanym produkcie,
pozwalający rozłożyć skomplikowany problem testowy
na elementarne części
53.Co to jest macierz przykrycia testów
akceptacyjnych? Podaj przykłady.
Macierz przykrycia testów akceptacyjnych to sposób
przedstawienia powiązania przypadków testowych z
funkcjami systemu. Na jednej osi macierzy rozpisane są
wszystkie elementy systemu wymagające testowania.
Mogą być to funkcjonalności, przypadki użycia,
moduły, bądź inne jednostki składowe systemu. Na
drugiej osi rozpisane zostają przypadki testowe. Na
przecięciu osi zaznacza się jeśli przypadek testowy
bada dany element systemu. Dzięki macierzy
przykrycia testów możliwe jest szybkie wykrycie
nadmiarowych przypadków testowych, albo
elementów, które nie są testowane.
54.Omów podstawowe schematy testów
integracyjnych. Podaj przykłady.
-Skokowe - grupują wybrane (lub wszystkie) jednostki
w celu ich równoczesnego przetestowania
-Przyrostowe - zakładają dołączenie do tworzonej
całości za każdym razem tylko jednej uprzednio
przetestowanej jednostki:
– zstępujące (odgórne) - integruje się i testuje się
komponenty wysokiego poziomu przed ukończeniem
ich projektu i implementacji; np.: (Namiastka (stub):
- imituje jednostki niższego poziomu
- zastępuje moduły wywoływane przez
testowany moduł )
– wstępujące (oddolne) - testuje się i integruje
komponenty niskiego poziomu przed ukończeniem
budowy komponentów wyższego poziomu;np.:(
Sterownik (driver):
- dostarcza jednostkom niższego poziomu dane
- zastępuje moduł wywołujący testowane moduły)
55.Jaka jest istota konstrukcyjnych wzorców
projektowych? Przedstaw przykład wzorca
konstrukcyjnego.
-Służą do pozyskiwania obiektów;
-Opisują szczegółowo, jak obiekt może zostać stworzony,
-Czynią kod niezależnym od typów tworzonych obiektów;
-Wybór konkretnej klasy uzależniany jest np. od
parametrów konfiguracyjnych;
-Przykłady:
-Singleton,
-Fabryka,
-Metoda Fabrykująca,
-Fabryka Abstrakcyjna,
-Budowniczy,
-Prototyp;
56.Jaka jest istota strukturalnych wzorców
projektowych? Przedstaw przykład wzorca
strukturalnego.
Strukturalne wzorce projektowe
- Zastosowanie np. w implementacji złożonego interfejsu
użytkownika;
- Stosowane do łączenia obiektów w większe struktury
Jednym z przykładów jest Fasada:
- Ujednolicony i prostszy interfejs do struktury złożonych
podsystemów;
- Separacja klienta od złożonych podsystemów;
- Wybór odpowiedniej struktury dla żądania klienta;
- Możliwości zmian w ukrywanych podsystemach;
Np.
- w bibliotekach Javy: klasy pakietu java.sql (Statement,
ResultSet);
- wejście usług w Service Oriented Architecture (SOA);
57.Jaka jest istota czynnościowych wzorców
projektowych? Przedstaw przykład wzorca
czynnościowego.
Wzorce czynnościowe inaczej zwane operacyjnymi, służą
do:
- definiowanie komunikacji pomiędzy obiektami;
- kontrolowanie przepływów danych w złożonych
algorytmach (programach);
- przydział zobowiązań obiektom;
Jednym z przykładów może być iterator:
- Upraszcza przemieszczanie po kolekcji danych (np.
liście), z wykorzystaniem standardowego interfejsu;
- Nie wymaga znajomości wewnętrznej struktury kolekcji
danych;
- Umożliwia równoczesne przeglądanie kilku kolekcji;
Np.
- W bibliotekach Javy: iterator w kolekcjach z pakietu
java.util;