21. Opisują funkcje wykonywane przez system,
które mogą być również wykonywane przy użyciu
systemów zewnętrznych.
Określenie wymagań funkcjonalnych obejmuje:
-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
16. PRINCE2:
+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
-zbyt pracochłonne w zastosowaniu do małych
projektów -ciągła wymiana informacji
powoduje pojawienie się bezproduktywnych
10. 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ń.
9. - 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
8. Model kaskadowy: zawiera ciag czynnosci
wykonywanych sekwencyjnie przy tworzeniu
oprogramowania: -okreslenie wymagan -analiza
-projektowanie -implementacja -testowanie
-konserwacja
wady: Narzucenie twórcom oprogramowania ścisłej
kolejności wykonywania prac
Wysoki koszt błędów popełnionych we wczesnych
fazach
Długa przerwa w kontaktach z klientem
Wytwarzanie ewolucyjne: opracowanie wstępnej
implementacji, pokazaniu jej użytkownikowi z
prośbą o komentarze oraz udoskonalaniu jej w
wielu wersjach aż do powstania odpowiedniego
systemu;
prototypowanie: sposób na uniknięcie zbyt
wysokich kosztów błędów popełnionych w fazie
określania wymagań. Zalecany w przypadku, gdy
określenie początkowych wymagań jest
stosunkowo łatwe. Fazy: -ogólne określenie
wymagań -budowa prototypu -weryfikacja
prototypu przez klienta -pełne określenie wymagań
-realizacja pełnego systemu zgodnie z modelem
kaskadowym
model V polega na wytwrzaniu rownlolegle
oprogramowania i prowadzeniu testow akceptacji,
poszczegolne elementy systemu sa badane po
wytworzeniu, praca polega na podziale systemu na
podsystemy, a te na poszczegolne zadania, co robi
jeden z zespolow, a drugi zespol odpowiada
wylacznie za ocene i testowanie systemu
model spiralny
opiera sie na ewolucyjym projekcie, ktory jest
poczatkowo planowany, nastepnie nastepuje
analiza ryzyka systemu, konstrukcja (czesto
odbywa sie zgodnie z modelem kaskadowym) a
7. 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.
6. 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
4. 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
3. 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.
5. ZASADA DEKOMPOZYCJI Czyli rozdzielenie
złożonego problemu na podproblemy,
ZASADE ABSTRAKCJI Czyli eliminacja,mniej
istotnych szczegółów rozważanego
przedmiotuwyodrębnianie cech wspólnych
pewnego zbioru bytów i wprowadzaniu pojęć
oznaczających te cechy.
ZASADE PONOWNEGO UZYCIA Czyli
wykorzystanie wcześniej wytworzonych
schematów, metod,
ZASADE SPRZYJANIA NATURALNYM LUDZKIM
WLASNOSCIOM Czyli dopasowanie modeli
pojęciowych i modeli realizacyjnych systemów
2. Semiotyka - jeden z trzech głównych (obok
logiki formalnej i metodologii nauk) działów
logiki, sam dzielący się na semantykę,
pragmatykę i syntaktykę. Podział semiotyki na
trzy główne działy pochodzi od Charlesa W.
Morrisa. Semiotyka logiczna stanowi ogólną
teorię znaków, zwłaszcza znaków językowych –
wyrażeń.
Semantyka bada relacje semantyczne, tj.
związki między znakami, a rzeczywistością,
tym, do czego odnoszą się znaki. Syntaktyka
bada relacje syntaktyczne, tj. relacje
zachodzące między samymi znakami. Nie są to
jednak wszystkie relacje zachodzące wewnątrz
języka, ale jedynie te, które mają charakter
formalny - a więc niezależne od znaczenia
wyrażeń, między którymi zachodzą.
Pragmatyka, która bada relacje pragmatyczne,
zachodzące między znakiem a jego
użytkownikami (nadawcami i odbiorcami), ma
częściowo nieuregulowany status - istnieje
wiele prób uczynienia z niej nauki formalnej na
wzór semantyki i syntaktyki, może ona jednak
1. 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.
38. 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 (np. za pomocą debuggera). 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
32. Diagram zależnosci służy do przedstawiania
złożonych zależnosci miedzy przyczynami i
skutkami. Diagramy zależnosci pozwalają odnaleźć
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, oraz w identyfikacji efektów
ubocznych tych działan.
Diagram przepływu danych DFD jest graficzną
prezentacją przepływu danych w procesie,
obrazujący za pomocą przepływów kierunek
przepływu danych pomiędzy funkcjami,
magazynami i obiektami zewnętrznymi. Na proces
składają się następujące elementy:
-Funkcje —realizują określone cele;
-Magazyny danych — trwałe lub tymczasowe
składnice danych, argumenty funkcji.
-Terminatory — obiekty, które nie są częścią
systemu, ale stanowią odbiorców bądź źródła
27. Analiza za pomocą narzędzi modelowania:
– diagramów przepływu danych– diagramów
obiekt-relacja-atrybut– diagramów przejść stanów
Na podstawie: – modeli otoczenia, – modeli
zachowania 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:
– wyodrębnienie części implementowanych;
– przydzielenie poszczególnych części specyfikacji
do odpowiednich procesorów lub serwerów –
zaprojektowanie struktury hierarchii modułów
danego zadania; – transformacja diagramów ERD
na relacyjną bazę danych
Implementacja:
– realizowane jest kodowanie i integracja modułów;
26. 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 istotne cechy oprogramowania na
wysokim poziomie abstrakcji. -Model ten
jednakże nie zastępuje doświadczenia, lecz
pomaga projektantom w zastosowaniu tych
walorów.
Czynności w fazie analizy:
-Rozpoznanie, wyjaśnianie, modelowanie,
specyfikowanie i dokumentowanie przedmiotu
20. Wymagania funkcjonalne (np. biblioteka)
–jakie usługi ma oferować system, jak ma
reagować na określone dane wejściowe oraz jak
ma się zachowywać w określonych sytuacjach.
– czego system nie powinien robić.
(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ące ograniczenia czasowe, ograniczenia
dotyczące procesu tworzenia, standardy itd.
(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ć bezbłędnie wszystkich funkcji
systemu po szkoleniu trwającym dwie godziny.)
Wymagania dziedzinowe funkcjonalne lub
niefunkcjonalne
– Są wyrażone za pomocą języka specyficznego dla
dziedziny zastosowania;
– Pochodzą z dziedziny zastosowania systemu -
odzwierciedlają jej charakterystykę.
(a) Wszystkie bazy danych powinny być dostępne
przez jednolity interfejs. 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
22. Opisują ograniczenia, przy których system ma
realizować swoje funkcje. 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.
-Wymagania dotyczące produktu. (możliwość
operowania z systemem wyłącznie za pomocą
ekranu.)
-Wymagania dotyczące procesu. (proces realizacji
harmonogramowania zleceń musi być zgodny z
konkr. standardem)
-Wymagania zewnętrzne. (system
23. Metody specyfikacji wymagań:
-Język naturalny - najczęściej stosowany.
Wady: niejednoznaczność; elastyczność,
utrudniająca wykrycie powiązanych wymagań i
utrudniająca wykrycie sprzeczności.
-Formalizm matematyczny. Stosuje się rzadko
-Język naturalny strukturalny. Język naturalny z
ograniczonym słownictwem i składnią,
wypunktowane tematy i zagadnienia.
-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 bloku i powiązań z otoczeniem
-Diagramy przypadków użycia: poglądowy
sposób przedstawienia aktorów i funkcji
24. -Streszczenie -Spis treści -Status
dokumentu
1. Wstęp 1.1. Cel 1.2. Zakres 1.3. Definicje,
akronimy i skróty 1.4. Referencje, odsyłacze
1.5. Krótki przegląd 2. Opis 2.1. Walory
użytkowe i przydatność projektu
2.2. Możliwości projektu 2.3. Ograniczenia 2.4.
Charakterystyka użytkowników 2.5.
Środowisko2.6. Założenia i zależności 3.
Wymagania 3.1. Wymagania funkcjonalne 3.2.
-Wymagania niefunkcjonalne.
-Dodatki
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
25. Celem fazy analizy jest ustalenie
wszystkich tych czynników lub warunków w
dziedzinie przedmiotowej, 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ń.
Czynności:
-Rozpoznanie, wyjaśnianie, modelowanie,
specyfikowanie i dokumentowanie przedmiotu
19. Podstawowe metody rozpoznania
wymagań:
- Wywiady i przeglądy. Wywiady powinny
doprowadzić do szerokiej zgody i akceptacji
projektu. - Studia na istniejącym
oprogramowaniem. 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.
Dobry opis wymagań powinien:
- Być kompletny oraz niesprzeczny. - Opisywać
zewnętrzne zachowanie się systemu -
18. 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ć czy system przy
ograniczonych środkach będzie spełniał cele w
okreś. środ.
2. Określenie i analiza wymagań 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ń
ustrukturalizowany zapis wykorzystujący język
17. 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
14. 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
operowaniu na 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
15. 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
13. Sponsor Projektu-członek zarządu klienta lub
jego bezpośredni rzedstawiciel,odpowiedzialny za
finansowanie całego przedsięwzięcia mają prawo
do wglądu w projekt i podejamowania decyzji na
temat jego dalszego rozwoju Rada Projektu-
zawiera w swoim ciele reprezentację wszystkich
uczestników projektu, 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, podlegają mu plany i
dokumentacja projektu wraz z produkatami i ich
testami. Komitet Kontroli Zmian składa się z
przedstawicieli zarówno dostawcy jak i klienta.
Jego skład wyznacza Rada Projektu Komitet
Akceptacyjny składa się przeważnie z
przedstawicieli obu stron, często jednak spotyka
się w nim wyłącznie przedstawicieli klienta
(przyjęcie lub odrzucenie produktu)
12. Projekt, to sposób prowadzenia
przedsięwzięć gospodarczych zmierzający do
wytworzenia produktu uzasadnionego
biznesowo, w ramach określonego czasu,
budżetu, z odpowiednią strukturą
organizacyjną , rolami i zakresami
odpowiedzialności. Wymiary zarządzania:
produkt, Koszt Hormonogram Jakość.Produkty
projektu - wszystkie jego elementy, które
mogą powstać w wyniku jego realizacji Budżet
projektu stanowi zestawienie kosztów realizacji
projektu. Wymiar jakości: - oceny zarówno
poszczególnych produktów projektowych: -
11. Umiejętność pracy w stresie. Zdolności
adaptacyjne. 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ęć,
11. Umiejętność pracy w stresie. Zdolności
adaptacyjne. 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ęć,
57. 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.
56.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.
55. -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,
54. -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
53. Testy akceptacyjne:
– Pozwalają sprawdzić, na ile oprogramowanie
działa zgodnie z wymaganiami klienta;
– Leżą w gestii klienta lub użytkownika
systemu oraz również współudziałowcy;
– Szukanie defektów nie jest głównym celem
tego testowania;
– Dzielą się na testy:
» użytkownika - weryfikuje dopasowanie
systemu do potrzeb użytkowników;
» operacyjne - akceptacja systemu przez
administratorów systemu zawierające:
sprawdzenie kopii zapasowej i zdolności do
przywrócenia funkcjonalności po wystąpieniu
problemów, zarządzanie użytkownikami,
zadania serwisowe, cykliczne sprawdzenie
bezpieczeństwa;
» kontraktowe i regulacyjne - testowanie
kryteriów wytworzenia oprogramowania
specyfikowanego dla klienta (np. są
wykonywane w zgodzie z rządowymi lub
legislacyjnymi uregulowaniami);
52. 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
51. 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
50. 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
48. 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
49. Użyteczność - dostępność oczekiwanych
usług
Niezawodność – np. prawdopodobieństwo
błędu w czasie realizacji transakcji, średni czas
pomiędzy błędnymi wykonaniami, dostępność
(procent czasu, w którym system jest
dostępny), czas restartu po awarii systemu,
prawdopodobieństwo zniszczenia danych w
przypadku awarii.
Wielokrotne użycie – ponowne wykorzystanie
gotowych elementów
Pielęgnacyjność – podatność na pielęgnowanie,
łatwość wprowadzania zmian
Przenośność – np. procent kodu zależnego od
platformy docelowej, liczba platform
docelowych, koszt przeniesienia na nową
43. - 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. 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
45. 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
46. Testowanie oprogramowania jest jednym z
procesów kontroli jakości oprogramowania i
jednym z kluczowych etapów procesu zapewnienia
jego jakości. Celem testowania oprogramowania
jest sprawdzanie jak dobry jest docelowy produkt
oraz sprawdzenie czy spełni swoje zadanie. Wsód
testów wyróżniamy testy dynamiczne oraz testy
statyczne. Testowaniu oprogramowania
podlega:Wydajność systemu, interfejsy systemu,
własności operacyjne systemu, testy zużycia
zasobów oraz zabezpieczenie systemu
Weryfikacja - testowanie zgodności systemu z
wymaganiami zdefiniowanymi w fazie określenia
wymagań - 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 zgodności
z wymaganiami użytkownika; sprawdzanie
zgodności z wymaganiami na oprogramowanie;
testowanie jednostek oprogramowania (modułów);
testowanie integracji oprogramowania, testowanie
systemu; testowanie akceptacji systemu przez
47. Badanie prognostyczne przeprowadzane są
wtedy gdy nie ma kodu źródłowego.
Głównymi zaletami podejścia prognostycznego
jest: Zwiększenie prawdopodobieństwa
uniknięcia lub zmniejszenia oddziaływania
zjawiska propagacji błędów; stosunkowo niskie
koszty testowania oraz możliwość przebadania
wielu różnych projektów oprogramowania w
celu wyboru najlepszego do implementacji.
Wadą podejścia prognostycznego jest
bazowanie na modelu oprogramowania, co
może zmniejszyc dokładność badania
(potencjalna rozbieżność z właściwościami
implemetacyjnymi). Metody prognostyczne
bazują na: metodach specyfikacji formalnej
programów; badaniu logiki sterowania
programów oraz na metrykach projektu
oprogramowania. Wyróżniamy dwa
42. - 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
41. 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
39. - 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;
36.
- 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
Wady: zmniejszenie dokładności badania
-badania diagnostyczne:
Typy: - Analiza dynamiczna - analiza statyczna
- inspekcje - audyty
40. 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, +
37. 1. Rozporządzenie określa:
1) metodykę , warunki i tryb sporządzania
testów akceptacyjnych;
2) sposób postępowania w zakresie badania,
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
35. Inspekcja to formalna technika oceny, w
której wymagania na oprogramowanie, projekt
lub kod są badane przez osoby zewnętrzne w
celu identyfikacji problemów.
- 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 testów - mniejsze koszty pielęgnacji -
poprawa procesu programowego - większy
34. Audytem nazywany jest niezależny
przegląd i ocenę jakości oprogramowania,
która zapewnia zgodność z wymaganiami na
oprogramowanie, specyfikacją, założeniami,
standardami, procedurami, wymaganiami.
Audyt powinien być przeprowadzany przez
odpowiednią organizację audytu lub przez
osoby posiadające uprawnienia/licencję
audytorów.
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
33.
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
28. 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;
Programowanie obiektowe
– realizacja projektu oprogramowania za
pomocą języka programowania obiektowego; –
języki obiektowe umożliwiają bezpośrednią
29. 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 .
Wyznaczniki jakości systemu informatycznego:
zgodny z wymaganiami użytkownika
30. Diagram klas –najczęściej wykorzystywany
statyczny diagram strukturalny, przedstawiający
strukturę systemu w modelach obiektowych przez
ilustrację struktury klas i zależności między nimi.
Zawiera: -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 obiektów - zamiast klas pokazuje
instancje. Wyjaśnia drobne elementy ze
skomplikowanymi relacjami.
Diagram komponentów - 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, aby uprościć
skomplikowane diagramy klas. Pakiet to zbiór
logicznie powiązanych elementów UML.
Diagram wdrożenia - obrazuje konfigurację
31. Diagramy przypadków użycia opisują, co
robi system z punktu widzenia zewnętrznego
obserwatora, pozostają w bliskim związku ze
scenariuszami.
Przypadek użycia to podsumowanie scenariuszy
pojedynczego zadania lub celu. Aktor to inicjator
zdarzenia związanego z zadaniem, określający
odgrywaną rolę. Jeden przypadek użycia może
mieć wielu aktorów.
Diagramy przypadków użycia mają zastosowania:
-Określanie wymagań
-Komunikacja z klientami.
-Generowanie przypadków testowych.
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.
Diagram czynności to szczególny przypadek
diagramu stanów, który obrazuje strumień kolejno
wykonywanych czynności, obrazuje przepływ
sterowania. Przedstawia sekwencyjne kroki
procesu obliczeniowego, zawiera stany przejścia
oraz obiekty.
Diagram sekwencji zdarzeń Opisują one, jak
obiekty ze sobą współpracują, w jaki sposób są
wykonywane operacje - jakie komunikaty są