Twoim problemem jest to, że powszechną NICOŚĆ mylisz z osobistą PUSTKĄ
1. Omów przedmiot i zakres inżynierii
oprogramowania.
Inżynieria oprogramowania:
dziedzina
inżynierii, która obejmuje wszystkie
aspekty tworzenia oprogramowania od fazy
początkowej do jego pielęgnacji
.
Jest
wiedzą empiryczną, syntezą doświadczenia
wielu ośrodków zajmujących się budową
oprogramowania
.
Informatyka obejmuje
teorie i podstawowe zasady działania
komputerów, a inżynieria oprogramowania
obejmuje praktyczne problemy
konstruowania oprogramowania
.
Zajmuje
się efektywnymi teoriami, metodami i
narzędziami związanymi z procesem
wytwarzania oprogramowania
.
Zastosowanie systematycznego,
zdyscyplinowanego, ilościowego podejścia
do wykonywania, wykorzystywania i
konserwowania oprogramowania [IEEE 93]
Zakres:
Sposoby prowadzenia
przedsięwzięć informatycznych. Techniki
planowania, szacowania kosztów,
harmonogramowania i monitorowania
przedsięwzięć informatycznych. Metody
analizy i projektowania systemów. Techniki
zwiększania niezawodności
oprogramowania. Sposoby testowania
systemów i szacowania niezawodności.
Sposoby przygotowania dokumentacji
technicznej i użytkowej. Procedury kontroli
jakości. Metody redukcji kosztów
konserwacji (usuwania błędów, modyfikacji
i rozszerzeń) Techniki pracy zespołowej i
czynniki psychologiczne wpływające na
efektywność pracy.
oprogramowanie, sieć, języki, narzędzia,
udogodnienia
. Zespół projektantów
–
podlega ograniczeniom pamięci, percepcji,
wyrażania informacji i komunikacji.
Potencjalni użytkownicy
– czynniki
psychologiczne ergonomia, ograniczenia
pamięci i percepcji, skłonność do błędów i
nadużyć, tajność, prywatność.
potem przychodzi czas na testy modułów,
potem integrację i walidację podsystemów,
następnie systemu. Ostatnią fazą są testy
akceptacyjne systemu.
Specyfikacja \
projekt systemu \ projekt podsystemu \
projekt modułu \ kodowanie, wstępne
testowanie modułu / formalne testowanie
modułu /
integracja i walidacja podsystemu
/ integracja i walidacja systemu / testy
akceptacyjne systemu.
Wytwarzanie przyrostowe
/ewolucyjne:
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
sie tworzenie badawcze (praca z klientem)
oraz prototypowanie (praca z elementami
systemu budzącymi wątpliwości)
Wady
:
Proces nie jest widoczny; System ma złą
strukturę; Konieczne mogą być specjalne
narzędzia i techniki;
Model spiralny
opiera się na
ewolucyjnym projekcie, który jest
początkowo planowany, następnie
następuje 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 wprowadzane są poprawki dopóki
klient nie zaakceptuje systemu.
Programowanie odkrywcze:
określ
ogólne wymagania
,
zbuduj system,
przetestuj system
,
zadowala? goto 5 : goto
2;
dostarcz system
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.
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 79 miesięcy
przynosi w informatyce zmiany, które w
innych dziedzinach zajmują 57 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!
Czynniki psychologiczne mają zasadniczy
wpływ na efektywność pracy zespołu.
Wyróżnia się następujące typy
psychologiczne:
Zorientowani na
zadania
(taskoriented). Osoby
samowystarczalne, zdolne, zamknięte,
agresywne, lubiące współzawodnictwo,
niezależne.
Zorientowani na siebie
(selforiented). Osoby niezgodne,
dogmatyczne, agresywne, zamknięte,
lubiące współzawodnictwo, zazdrosne.
Zorientowani na interakcję
(interactionoriented). 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.
5. Omów sposoby opanowywania
złożoności projektu informatycznego.
Zasada dekompozycji
– rozdzielenie
problemu na podproblemy, które można
rozpatrywać i rozwiązywać niezależnie od
siebie i niezależnie od całości.
Zasada
abstrakcji –
eliminacja, ukrycie lub
pominięcie mniej istotnych szczegółów
rozważanego przedmiotu lub mniej
istotnych informacji; wyodrębnienie cech
wspólnych i niezmiennych dla pewnego
zbioru bytów i wprowadzenie pojęć lub
symboli oznaczających takie cechy
Zasada
ponownego użycia
– wykorzystanie
wcześniej wytworzonych schematów,
metod, wzorców, komponentów projektu,
komponentów oprogramowania itd.
Zasada sprzyjania naturalnym
ludzkim własnościom
– dopasowanie
modeli pojęciowych i modeli realizacyjnych
systemów do wrodzonych ludzkich
własności psychologicznych, instynktów
oraz mentalnych mechanizmów percepcji i
rozumienia świata.
6. Omów zagadnienie modelowania
pojęciowego w projekcie
informatycznym.
Projektant i programista muszą dokładnie
wyobrazić sobie problem oraz metodę jego
rozwiązania. Zasadnicze procesy tworzenia
oprogramowania zachodzą w ludzkim
umyśle i nie są związane z jakimkolwiek
językiem programowania. Pojęcie
modelowania pojęciowego (conceptual
modeling) oraz modelu pojęciowego
(conceptual model) odnoszą się do
procesów myślowych i wyobrażeń
towarzyszących pracy nad
oprogramowaniem. Modelowanie
pojęciowe jest wspomagane przez środki
wzmacniające ludzką pamięć i wyobraźnię,
Służą one do przedstawienia rzeczywistości
opisywanej przez dane procesów
zachodzących w rzeczywistości, struktur
danych oraz programów składających się
na konstrukcję systemu. Trwałą
tendencją w rozwoju metod i narzędzi
projektowania oraz konstrukcji SI jest
dążenie do minimalizacji luki pomiędzy
myśleniem o rzeczywistym problemie, a
myśleniem o danych i procesach
zachodzących na danych. Perspektywy w
modelowaniu pojęciowym: Percepcja
rzeczywistego świata <odwzorowanie>
Analityczny model rzeczywistości <
odwzorowanie > Model struktur danych i
procesów SI .
2. Omów zagadnienie języka
programowania i semiotyki języka
programowania.
Język programowania jest środkiem
umożliwiającym zapis algorytmów w
postaci zrozumiałej dla człowieka, a
równocześnie przetwarzalnej do postaci
zrozumiałej dla komputera (maszyny
algorytmicznej)
Semiotyka zajmuje się badaniem symboli,
znaków. W jej skład wchodzą:
Syntaktyka(formalna i logiczna), zajmująca
się określeniem przynależności danego
słowa do zestawu słownika określonego
języka programowania. //składnia języka.
semantyka, zajmująca się określeniem
znaczenia programu, zapisanego w
określonym języku programowania.
Językami programowania, badaniem ich
algorytmiczności zajmuje się syntaktyka
języków programowania, która jest jednym
z rodzajów syntaktyk formalnych.
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
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.”
W
Prince2
skoncentrowano się na
określeniu zasad organizacji i zarządzania
projektem, co ma w przekonaniu jej
autorów gwarantować prawidłowe jego
rozpoczęcie i doprowadzenie do
pomyślnego zakończenia oraz
wypracowanie oczekiwanych produktów,
przy jednoczesnym dotrzymaniu
planowanego czasu, budżetu i jakości
projektu. Dzięki oddzieleniu grupy
zarządczej, odpowiedzialnej za organizację
i kierowanie, od technicznej wytwarzającej
produkt, może ona znaleźć zastosowanie w
wielu dziedzinach
Produkt:
Przez
produkty projektu rozumie
się wszystkie jego elementy, które mogą
powstać w wyniku jego realizacji.
Może to
być gotowe oprogramowanie,
zainstalowane systemy, dokumentacja
oprogramowania, różnego rodzaju
procedury, wykształcone kadry
ludzkie itp.
Opracowanie planów działań w wymiarze
produktów odbywa się na podstawie
definicji zakresu projektu.
Wymiar czasu:
Na
podstawie precyzyjnie
zdefiniowanego zakresu projektu można
zdefiniować drugi wymiar projektu, czyli
czas, który jest najczęściej
zapisywany w
postaci harmonogramu.
Często
spotykaną
formą prezentacji harmonogramu są na
przykład tabele lub arkusze kalkulacyjne,
jak również wykresy Gantta, które
przedstawiają poszczególne czynności
projektowe w sieci uwzględniającej
wzajemne ich zależności, następstwa i
zasoby niezbędne do ich
wykonania w
odpowiednio zdefiniowanej skali czasu.
Koszt:
Budżet
projektu stanowi
zestawienie kosztów realizacji projektu.
Koszt
ten powinien być podzielony na
poszczególne jego kategorie(koszty
3. Omów zagadnienie i skutki tzw.
„kryzysu oprogramowania”.
Syndrom LOOP(Late, Over budżet,
Overtime,Poor quality)
Podstawowym powodem kryzysu
oprogramowania jest złożoność produktów
informatyki i procesów ich wytwarzania”
Zasadnicze problemy wytwórców
oprogramowania: wzrost mocy sprzętu
zwiększa zapotrzebowanie na nowe,
bardziej złożone oprogramowanie; długi i
kosztowny cykl wytwarzania
oprogramowania; frustracje projektantów
oprogramowania i programistów
wynikające ze zbyt szybkiego postępu w
zakresie języków, narzędzi i metod;
uzależnienie organizacji od systemów
komputerowych i przyjętych technologii
przetwarzania informacji, które nie są
stabilne w długim horyzoncie czasowym;
brak kontaktów pomiędzy użytkownikiem i
firmą; problemy współdziałania niezależnie
zbudowanego oprogramowania,
szczególnie istotne przy dzisiejszych
tendencjach
integracyjnych; niska kultura ponownego
użycia wytworzonych komponentów
projektów i oprogramowania; zbyt późne
wykrywanie błędów i słabych punktów;
brak koordynacji w pracy zespołów
projektowych; ogromne koszty utrzymania
oprogramowania;
Skutki:
27% projektów powstaje w
założonym czasie, budżecie i
funkcjonalności,
33% projektów przekracza
czas, budżet i ma mniejszą funkcjonalność
,
40% projektów jest przerywanych
53%
projektów przekracza koszty o 51%
,
68%
projektów przekracza czas o 51%
,
69%
niepowodzeń to czynniki
pozainformatyczne.
10. Omów podstawowe czynniki
psychologiczne w procesie
wytwórczym i rodzaje osobowości
twórców oprogramowania
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:
1.
Osobowość ludzka ma charakter
dynamiczny (zmienia się). Wieloletnia
praktyka zawodowa nie pozostaje bez
wpływu na osobowość.
2.
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ń.
3.
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
7. Co to jest metodyka prowadzenia
projektu informatycznego?
Metodyka jest to zestaw pojęć, notacji,
modeli, języków, technik i sposobów
postępowania służący do analizy dziedziny
stanowiącej przedmiot projektowanego
systemu oraz do projektowania
pojęciowego, logicznego i/lub fizycznego.
Metodyka powiązana jest z notacją służącą
do dokumentowania wyników faz projekt
(pośrednich, końcowych), jako środek
wspomagający ludzką pamięć i wyobraźnię
i jako środek komunikacji w zespołach oraz
pomiędzy projektantami i klientem.
Metodyka ustala:
+fazy projektu, role uczestników projektu,
+modele tworzone w każdej z faz,
+scenariusze postępowania w każdej z faz.
+reguły przechodzenia od fazy do
następnej fazy,
+notacje, których należy używać,
+dokumentację powstającą w każdej z faz
8. Omów następujący model cyklu
życia oprogramowania: … nazwa
modelu
Model kaskadowy
: ciąg czynności
wykonywanych sekwencyjnie: 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
Model V
Od specyfikacji przechodzi się do
projektu pełnego systemu, który
dekomponuje się na projekty
podsystemów, a te z kolei na projekty
modułów. Kolejną
fazą jest kodowanie,
4. Omów przykładowe źródła
złożoności projektu informatycznego.
Dziedzina problemowa
– obejmuje
ogromną liczbę wzajemnie uzależnionych
aspektów i problemów.
Środki i
technologie informatyczne
– sprzęt,
osobowe,
koszty sprzętu,
administracji
projektu,
delegacji,
szkoleń itp.)
Wymiar jakości
oceny zarówno
poszczególnych produktów
projektowych(dokumentacji,
oprogramowania, platformy techniczno
systemowej itp.) jak i oceny organizacji
procesu projektowego(planu wzajemnych
oddziaływań procesów projektowych,
zasobów ludzkich zaangażowanych w
projekt, zarządzania poszczególnymi
wymiarami projektu itp.)
Harmonogramem(czasem)
obejmuje
procesy wymagane do zapewnienia
przestrzegania przez zespół projektowy
ustalonych granic czasowych dla
poszczególnych czynności w projekcie.
Główne procesy to: definiowanie czynności,
sekwencjonowanie czynności, estymowanie
czasu, opracowanie harmonogramu,
kontrola wykonania harmonogramu,
zarządzanie zmianami harmonogramu
Jakością
obejmuje procesy wymagane do
zapewnienia zaspokojenia przez rezultaty
projektu tych potrzeb, dla których został on
powołany. Główne procesy to: planowanie
jakości, zapewnienie jakości, kontrola
jakości
Komunikacją
obejmuje procesy służące
zapewnieniu terminowego i właściwego
tworzenia, gromadzenia,
rozpowszechniania, przechowywania i
usuwania informacji niezbędnej do
efektywnego zarządzania projektem.
Główne procesy: planowanie komunikacji,
dystrybuowanie informacji,
sprawozdawczość
Integracją
obejmuje procesy wymagane
do zapewnienia poprawnej koordynacji
wszystkich elementów projektu. Główne
procesy: wypracowanie planu projektu,
wykonywanie planu projektu, ogólna
kontrola zmian projektu
Ryzykiem
obejmuje procesy identyfikacji,
analizowania i reakcji na zaistnienie
czynników ryzyka w projekcie. Główne
procesy: identyfikacja ryzyka, estymowanie
ryzyka, optymalizacja ryzyka,
monitorowanie ryzyka
Zasobami ludzkimi
obejmuje procesy
ułatwiające efektywne wykorzystanie ludzi
w projekcie (klientów, sponsorów i innych
uczestników).Główne procesy: planowanie
organizacji, nabór personelu, zarządzanie
zespołami ludzkimi.
Zaopatrywaniem/zleceniami/sprzeda
żą
obejmuje zdobywanie dóbr i usług
spoza organizacji wykonującej projekt
Główne procesy: planowanie zleceń,
planowanie ofert, realizacja ofert, selekcja
dostawców
19. Omów podstawowe metody
rozpoznawania wymagań i cechy
jakościowego dobrego opisu
wymagań.
Dobry opis wymagań powinien być:
Kompletny
,
Niesprzeczny
,
Weryfikowalny
,
Realizowalny
,
Opisywać zewnętrzne
zachowania systemu z pominięciem
sposobu jego realizacji
,
Obejmować
ograniczenia, przy jakich musi pracować
system
,
Łatwy w modyfikacji
,
Zapewniać
możliwości zmiany wymagań w kolejnych
etapach
,
Zawierać zachowania systemu w
niepożądanych lub skrajnych sytuacjach
Metody rozpoznawania wymagań:
Wywiady i przeglądy.
Wywiady powinny
być przygotowane (w postaci listy pytań) i
podzielone na odrębne zagadnienia.
Podział powinien przykrywać całość tematu
i powinny być przeprowadzone na
reprezentatywnej grupie użytkowników.
Wywiady powinny doprowadzić do
szerokiej zgody i akceptacji projektu.
Studia na istniejącym
oprogramowaniem
. Dość często nowe
oprogramowanie zastępuje stare. Studia
powinny ustalić wszystkie dobre i złe strony
starego oprogramowania.
Studia wymagań systemowych
.
Dotyczy sytuacji, kiedy nowy system ma
być częścią większego systemu.
Studia osiągalności
. Określenie
realistycznych celów systemu i metod ich
osiągnięcia.
Prototypowanie
. Zbudowanie prototypu
systemu działającego w zmniejszonej skali,
z uproszczonymi interfejsami.
Różnice w organizacji biura projektu
informatycznego w Prince2 i Chestr
SBS:
W zaleceniach Prince 2 wyróżnia się
szefa projektu od strony użytkownika i
dostawcy (tworzą oni zarząd projektu), w
Chestr jest jeden szef projektu
inaczej
zwany kierownikiem, posiadający silną
pozycje. Istotne różnice w administracji
projektu to: w Prince2 menedżer
konfiguracji(powoływany do
większych
projektów) który to w metodyce Chestr nie
jest składową administracji projektu a
dodatkowo w Chestr powołuje się
menedżerów budżetu i
jakości. Kolejną
różnicą jest w Chestr architekt systemowy i
biznesowy(określają zakres projektu i
produktu) natomiast w Prince2 sekretariat
biura projektu. Wyróżnionymi obszarami w
Chestr jest dokumentacja i testowanie. W
metodyce Prince2 dzięki oddzieleniu grupy
zarządczej, odpowiedzialnej za organizację
i kierowanie, od technicznej wytwarzającej
produkt, może ona znaleźć zastosowanie w
wielu dziedzinach.
Cechy:
W Prince2 skoncentrowano się na
określeniu zasad organizacji i zarządzania
projektem, co ma w przekonaniu jej
autorów gwarantować prawidłowe
jego
rozpoczęcie i doprowadzenie do
pomyślnego zakończenia oraz
wypracowanie oczekiwanych produktów,
przy jednoczesnym dotrzymaniu
planowanego czasu, budżetu i jakości
projektu.
13. Omów przykład struktury biura
projektu informatycznego,
zbudowanego według zaleceń
Prince2.
Szef projektu
jest personalnie
odpowiedzialny za sukces lub porażkę
projektu, decyduje na szczeblu
operacyjnym. Szefowie ze strony
użytkownika i ze strony dostawcy tworzą
Zarząd Projektu.
Szef projektu u
użytkownika
odpowiada za:
współorganizację prac projektowych i
zapewnienie zasobów dla projektu ze
strony klienta
Szef projektu u dostawcy
– odpowiada za: 1.organizowanie
(planowanie) projektu i prac oraz
korygowanie planów 2. ustalenie założeń,
wymagań użytkownika oraz kryteriów
akceptacji produktów projektowych 3.
kontrolę postępów i ich raportowanie
(produkt, czas, budżet) 4. Mianowanie
Szefów Zespołów i Sekretariatu Projektu 5.
dostarczenie produktów do testów i
akceptacji 6. zapewnienie zasobów ze
strony dostawcy 7. zorganizowanie prac
Komitetu Sterującego 8. kontakty z
poddostawcami.
Sekretariat
/administracja biura projektu –
wykonuje zadania w zakresie :
1.prowadzenia biblioteki projektu, planów,
raportów, wniosków o zmianę itp.
2.zarządzania korespondencją,
dokumentacją spotkań 3. zbierania i
konsolidacji raportów z zespołów
technicznych 4. przygotowania materiałów
do raportów Szefa Projektu 5. spraw
osobowych (urlopy, rozliczenia finansowe,
sprawy pracownicze itp.) 6. rozliczeń
finansowych z dostawcami zewnętrznymi 7.
rozliczeń finansowych z klientem
Zespoły Realizacyjne
są wykonawcami
produktów i dlatego od ich prawidłowego
składu i organizacji zależy powodzenie
realizacji projektu.
20. Omów główne klasy wymagań na
system informatyczny. Podaj
przykłady takich wymagań.
Wymagania funkcjonalne
Opisują
funkcje (czynności, operacje) wykonywane
przez system. Funkcje te mogą być również
wykonywane przy użyciu systemów
zewnętrznych. 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. NP:
system wymaga logowania użytkownika
możliwość sprawdzania postępów pracy w
każdym momencie
Wymagania niefunkcjonalne
Opisują
ograniczenia, przy których system ma
realizować swoje funkcje. To ograniczenia
usług i funkcji systemu. Obejmują
ograniczenia czasowe, ograniczenia
dotyczące procesu tworzenia, standardy
system powinien odszukiwać dane
każdego użytkownika poniżej 10 sekund
system nie powinien zajmować więcej niż
10GB
Wymagania dziedzinowe
Pochodzą z
dziedziny zastosowania systemu
odzwierciedlają jej charakterystykę. Mogą
być funkcjonalne lub niefunkcjonalne.
Wszystkie bazy danych powinny być
dostępne przez jednolity interfejs
użytkownika, którego podstawą jest
standard Z39.50.
17. Omów zagadnienie zarządzania
konfiguracją w przedsięwzięciu
informatycznym na podstawie
metodyki RUP.
RUP: Ukierunkowany na przypadki użycia,
Architekturocentryczny, Iteracyjny,
Przyrostowy Sterowany ryzykiem
Zarządzania konfiguracją
ma na celu:
1. identyfikacje i udokumentowanie
funkcjonalnych oraz niefunkcjonalnych
charakterystyk produktów projektowych 2.
monitorowanie wszelkich zmian tych
charakterystyk 3. zapisywanie i
raportowanie zmian oraz stopnia
implementacji zmian 4. Weryfikacje
poszczególnych produktów projektowych
pod względem spełniania wymagań
ustalonych dla tych produktów.
15. Omów przykład struktury biura
projektu informatycznego,
zbudowanego według zaleceń
metodyki Chestra SBS.
18. Omów zakres działania tzw.
„inżynierii wymagań” w procesie
wytwórczym oprogramowania.
Celem fazy określenia wymagań jest
ustalenie wymagań klienta wobec
tworzonego systemu. Dokonywana jest
zamiana celów klienta na konkretne
wymagania zapewniające osiągnięcie tych
celów. Proces inżynierii wymagań to:
wynajdowanie, analizowanie,
specyfikowanie i dokumentowanie
sprawdzania usług i ograniczeń W zakresie
inżynierii wymagań wyróżnia się:
wymagania użytkownika, wymagania
systemowe, wymagania funkcjonalne i
niefunkcjonalne, dokumentacje wymagań
stawianych oprogramowaniu. Punktem
wyjściowym w projektowaniu w pełni
funkcjonalnej aplikacji są trzy podstawowe
elementy związane z inżynierią wymagań,
czyli: zebranie wymagań użytkowników,
zarządzanie tymi wymaganiami, czyli
zestawienie powstałej specyfikacji z
oczekiwaniami klienta, weryfikowanie tych
wymagań poprzez stałą komunikację
całego zespołu, aby upewnić się, że
powstaje odpowiednia aplikacja.
Projekt powinien odnosić się do trzech
poziomów wymagań: Wymagania
biznesowe(potrzeby) Wymagania
użytkownika(cechy) Wymagania
systemowe(funkcjonalne, niefunkcjonalne)
Kierownik Projektu(Szef projektu)
–
posiada silną pozycje
Architekt Systemowy i Biznesowy
–
określają zakres projektu i zakres produktu
Techniczne zarządzanie projektem
–
wyróżniono dokumentacje użytkownika i
obszary testów.
14. Omów podstawowe obszary
zarządzania przedsięwzięciem
informatycznym według metodyki
PMI.
21. Omów i podaj przykłady wymagań
funkcjonalnych dla systemu
informatycznego.
Wymagania funkcjonalne określają jakie
usługi ma oferować system, jak ma
reagować na otrzymywane dane wejściowe
oraz w określonych sytuacjach. Określają
one użytkowników korzystających z
systemu oraz możliwości każdego z nich.
Określają również wykorzystanie systemów
zewnętrznych. Mogą one również określać
czego system nie powinien robić.
Wymagania funkcjonalne mogą być
realizowane przez systemy zewnętrzne.
wprowadzenie nie pełnych danych system
powinien komunikować błędem
system powinien przydzielać odpowiednie
zlecenia pracownikom.
16. Porównaj zalecenia Prince2, PMI i
Chestra SBS w zakresie obszarów
zarządzania projektem
informatycznym i organizacji biura
projektu informatycznego.
Studiując metodyką Prince2 można odnieść
nieodparte wrażenie, że jest ona mocno
sugerowana osiągnięciami standardów
PMI. Wydaje się, że autorom metodyki
Prince2 zależało przede wszystkim na
pewnym zagregowaniu,
usystematyzowaniu i przełożeniu zasad
określonych w standardach
północnoamerykańskich na uwarunkowania
rynku europejskiego.
Różnice w zakresie zarządzania
projektem informatycznym w Prince2
i PMI:
Zakresem
– obejmuje procesy dające
pewność że projekt uwzględnia wszystkie
konieczne czynności niezbędne dla
pomyślnego zakończenia projektu i
uzyskania oczekiwanego zakresu produktu.
Główne procesy to: inicjowanie faz
projektu, planowanie zakresu, definiowanie
zakresu, weryfikacja zakresu, kontrola
zmian zakresu.
Kosztem
obejmuje procesy wymagane do
zapewnienia, że projekt zostanie
ukończony w ramach zaakceptowanego
budżetu. Główne procesy to: planowanie
zasobów, estymowanie kosztu,
przypisywanie kosztów (budżetowanie),
kontrola kosztu, zarządzanie zmianami
budżetu
22. Omów i podaj przykłady wymagaŃ
niefunkcjonalnych dla systemu
informatycznego.
Wymagania niefunkcjonalne są to
ograniczenia systemu, które obejmują
ograniczenia czasowe, ograniczenia
dotyczące procesu tworzenia, standardy.
Wynikają one z potrzeb użytkownika,
budżetu, potrzeby współpracy z innym
systemem, strategii firmy i czynników
zewnętrznych. Wymagania niefunkcjonalne
można podzielić na trzy podklasy:
Produktowe (określają zachowanie
produktu) : system powinien być łatwy w
użyciu dla doświadczonych kontrolerów
Organizacyjne (wynikają ze strategii w
firmie wytwórczej i firmie klienta)
proces tworzenia systemu i końcowe
dokumenty powinny być zgodne z
procesem i produktami zdefiniowanymi w
standardzie XYZCoSPSTAN95.
Zewnętrzne
system nie powinien ujawniać operatorom
żadnych danych osobowych klientów
oprócz nazwisk i numerów
identyfikacyjnych.
Uproszczony opis systemu; Hierarchiczna
dekompozycja funkcji systemu; Model
logiczny jest opisany przy pomocy notacji
zgodnej z pewną konwencją; Jest on
zbudowany przy użyciu dobrze
rozpoznanych metod i narzędzi; Jest on
używany do wnioskowania o przyszłym
oprogramowaniu; Model oprogramowania
powinien być jego uproszonym opisem,
opisującym wszystkie istotne cechy
oprogramowania na wysokim poziomie
abstrakcji.
Model ten jednakże nie zastępuje
doświadczenia i wnikliwości projektantów,
lecz pomaga projektantom w zastosowaniu
tych walorów.
Czynności w fazie analizy:
Rozpoznanie, wyjaśnianie, modelowanie,
specyfikowanie i dokumentowanie
rzeczywistości lub problemu będącego
przedmiotem projektu; Ustalenie
kontekstu projektu; Ustalenie wymagań
użytkowników; Ustalenie wymagań
organizacyjnych; Inne ustalenia, np.
dotyczące preferencji sprzętowych,
preferencji w zakresie oprogramowania,
ograniczeń finansowych, ograniczeń
czasowych, itd.
Analiza nie powinna stawiać nacisku na
zmianę rzeczywistości poprzez
wprowadzenie tam nowych elementów, jej
celem jest rozpoznanie wszystkich tych
aspektów rzeczywistości, które mogłyby
mieć wpływ na postać, organizację lub
wynik projektu.
1. warstwa tematów 2. warstwa klas i
obiektów 3. warstwa struktury 4. warstwa
atrybutów 5. warstwa usług
# Przykłąd Analiza metoda OMT
(metoda Rumbaugh)
OMT Object Modelling Technique
3 części składowe modelu, pokazujące
różne jego aspekty:
Model Obiektów (OMT Object Model)
statyczny obraz struktury modelu
klasy atrybuty operacje
relacje między klasami i instancjami
(powiązania asocjacje,
całość część (agregacje), gen spec)
Model Dynamiczny (OMT Dynamic Model)
współdziałanie obiektów (powiązania
wyznaczone przez komunikaty).
Tu mieszczą się różne diagramy pokazujące
przepływ sterowania,
także ograniczenia i warunki na wartości
atrybutów.
Model Funkcyjny (OMT Functional Model)
specyfikacja operacji jako funkcji
przekształacących wejście na
wyjście, warunki poprawności (asercje).
# Ogólnie w temacie o analizie
obiektowej
– opracowanie modelu obiektowego
dziedziny zastosowania;
– rozpoznane obiekty odzwierciedlają byty i
operacje związane z rozwiązywanym
problemem;
Projektowanie obiektowe
– opracowanie modelu obiektowego
systemu oprogramowania, który będzie
implementacją zidentyfikowanych
wymagań;
– obiekty projektu obiektowego są
związane z rozwiązaniem problemu;
Zadania w etapach fazy projektowania:
– uściślenie istniejących definicji klas, np.
metod,
– dziedziczenie klas i operacji,
– szczegółowy projekt operacji wraz z
przeprojektowaniem ich algorytmów,
– wprowadzenie ogólnych mechanizmów
realizacji dynamiki obiektów,
– decyzje o trwałości obiektów,
– modularyzacja i ukrywanie informacji,
– optymalizacja modelu,
– dokumentacja projektu;
Programowanie obiektowe
– realizacja projektu oprogramowania za
pomocą języka programowania
obiektowego;
– języki obiektowe umożliwiają
bezpośrednią implementację obiektów i
dostarczają udogodnienia do definiowania
klas obiektów;
wykorzystywanym diagramem w notacji
UML.
Diagram obiektów
(Object
Diagram)zamiast klas pokazują instancje.
Przydają się do wyjaśniania drobnych
elementów ze skomplikowanymi relacjami,
zwłaszcza rekurencyjnymi. Każdy prostokąt
na diagramie obiektów odpowiada
pojedynczej instancji. Nazwy instancji na
diagramach UML są podkreślone. Nazwy
klas lub instancji mogą zostać pominięte na
diagramach obiektów, pod warunkiem, że \
sens diagramu pozostaje jasny.
Diagram komponentów
(Component
Diagram) (zwany także diagramem
implementacji) to diagram przedstawiający
jeden z aspektów modelu zgodnego z UML.
Przedstawia fizyczne elementy wchodzące
w skład systemu i połączenia między nimi.
Komponenty przedstawiane za pomocą
dużego prostokąta, z dwoma mniejszymi
z jego lewej strony oraz z etykietą
w środku. Komponenty mogą być
przedstawiane zarówno jako klasy jak
i instancje. Klasa oznacza elementy
systemu istniejące podczas jego działania
(np. interfejs użytkownika czy dane).
Konkretne instancje precyzują o jaki
element chodzi (np. okno programu
będące częścią interfejsu). Węzły są to
zasoby sprzętowe dostępne podczas
działania systemu. Obrazowane są za
pomocą prostopadłościanów.
23. Omów metody specyfikacji
wymagań dla systemów
informatycznych.
W zależności od potrzeb stosuje się różne
metody specyfikacji wymagań:
Język
naturalny
najczęściej stosowany. Wady:
niejednoznaczność powodująca różne
rozumienie tego samego tekstu;
elastyczność, powodująca wyrazić te same
treści na wiele sposobów. Utrudnia to
wykrycie powiązanych wymagań i
powoduje trudności w wykryciu
sprzeczności.
Formalizm matematyczny
.
Stosuje się rzadko (dla specyficznych
celów).
Język naturalny strukturalny
. Język
naturalny z ograniczonym słownictwem i
składnią. Tematy i zagadnienia
wyspecyfikowane w punktach i
podpunktach.
Tablice, formularze.
Wyspecyfikowanie wymagań w postaci
tablic, kojarzących różne aspekty.
Diagramy blokowe:
forma graficzna
pokazująca cykl przetwarzania.
Diagramy
kontekstowe:
ukazują system w postaci
jednego bloku oraz jego powiązania z
otoczeniem, wejściem i wyjściem.
Diagramy przypadków użycia:
poglądowy
sposób przedstawienia aktorów i funkcji
systemu.
Diagram pakietów
– (Package
Diagram)to diagram służący do
porządkowania struktury systemu.
Stosowane, aby uprościć skomplikowane
diagramy klas, klasy grupujemy w pakiety.
Pakiet to zbiór logicznie powiązanych
elementów UML. Pakiety to prostokąty z
małymi zakładkami na górze. Nazwa
pakietu znajduje się na zakładce albo
wewnątrz prostokąta. Strzałki z
przerywanymi liniami to zależności. Jeden
pakiet jest zależny od drugiego, jeśli
zmiany w drugim pakiecie mogą wymusić
zmiany w pierwszym.
Diagram wdrożenia
(Deployment
Diagram) obrazuje konfigurację węzłów
działających w czasie wykonania i
zainstalowane na nich komponenty. Odnosi
się do statycznych aspektów perspektywy
wdrożeniowej. Wiąże się z diagramem
komponentów, ponieważ zwykle każdy
węzeł zawiera conajmniej jeden
komponent. Diagramy wdrożenia zawierają
na ogół węzły i powiązania między nimi. Są
przydatne do modelowania systemów
rozproszonych i typu klientserwer.
27.Omów przykłady nieobiektowego
podejścia do analizy, projektu i
implementacji systemów
informatycznych.
Metodyki strukturalne
łączą statyczny
opis danych oraz statyczny opis procesów.
Do tej klasy należą: Metodyka Yourdona
(DeMarco i Ward/Mellor); Structured
System Analysis and Design Methodology
(SSADM); Structured Analysis and Design
Technique (SADT).
Uważa się, że wadą metodyk
strukturalnych są trudności w
zintegrowaniu modeli oraz iż pomimo
dojrzałości,
mogą
nie być adekwatne
do
współczesnych tendencji wytwarzania
systemów informatycznych;
Przykład metodyki CDMOracle
1996
stosowana do procesów
biznesowych i funkcji, które nie mogą być
obsłużone za pomocą dostępnych aplikacji
„z półki”;
CDM jest zbiorem zdefiniowanych
procesów tworzenia oprogramowania,
które zostały określone przy założeniu, że
w procesie wytwórczym stosowane są
metody i narzędzia CASE;
zakłada, że potrzeby biznesowe zostają
wyraźnie zdefiniowane na samym początku
cyklu projektowego oraz że ich
zweryfikowanie jest możliwe podczas
całego procesu wytwórczego;
CDM wyróżnia następujące procesy:
definicja potrzeb biznesowych (studium
możliwości),
analiza istniejących systemów,
opracowanie architektury technicznej,
projektowanie i budowa bazy danych,
projektowanie i budowa modułów,
konwersja danych,
opracowanie dokumentacji technicznej,
testowanie,
szkolenie,
przejście na nowy system,
obsługa serwisowa;
24.Omów przykładowy zakres treŚci
dokumentu opisujĄcego wymagania na
system informatyczny.
Dokument opisujĄcy wymagania na system
informatyczny ma pewien schemat:
Informacje organizacyjne:
Streszczenie
(około 200 słów),
Spis treŚci
,
Statut dokumentu
(autorzy, firmy, podpisy),
Zmiany w stosunku do poprzedniej wersji.
Zasadnicza zawartoŚĆ dokumentu:
1.
WstĘp
(1.1 Cel 1.2 Zakres 1.3 Definicje
akronimy i skróty 1.4 Referencje,
odsyłacze do innych
dokumentów 1.5
Krótki przeglĄd )
2.
Ogólny opis
(2.1 Walory uŻytkowe i
przydatnoŚĆ projektowanego systemu 2.2
Ogólne moŻliwoŚci
projektowanego
systemu 2.3 Ogólne ograniczenia 2.4
Charakterystyka
uŻytkowników 2.5
Środowisko operacyjne 2.6 ZałoŻenia i
zaleŻnoŚci )
3.
Specyficzne wymagania
( 3.1 Wymagania funkcjonalne 3.2
Wymagania niefunkcjonalne )
Dodatki
KolejnoŚĆ i numeracja punktów w
przedstawionym spisie treŚci powinna byĆ
zachowana. W przypadku gdy pewien
punkt nie zawiera Żadnej informacji
naleŻy wyraŹnie to zasygnalizowaĆ przez
umieszczenie napisu „Nie dotyczy”.
Dla kaŻdego wymagania powinien byĆ
podany powód jego wprowadzenia: cele
przedsiĘwziĘcia, których osiĄgniĘcie jest
uwarunkowane danym
wymaganiem.
29. Co to jest system informatyczny i
jakie są jego główne wyznaczniki
jakości.
System informatyczny jest złożoną
konstrukcją, której stopień skomplikowania
zależy od złożoności architektury. Wielki
systemy są zwykle podzielone na
podsystemy, które oferują pewien zbiór
powiązanych ze sobą interfejsów; System
informatyczny to złożony program
komputerowy lub zespół współdziałających
ze sobą programów, przeznaczonych do
wykonywania określonych funkcji: np.
system operacyjny, system zarządzania
bazami danych . Najczęściej o systemie
informatycznym mówi się wtedy, gdy do
zbierania, gromadzenia, przesyłania i
przetwarzania danych zastosowane są
techniczne środki informatyki, a
przynajmniej komputer do przetwarzania.
Zestaw technicznych środków informatyki
jest przeznaczony do realizacji zadań
określonych przez system informacyjny .
Podsumowując – system informatyczny to
określony obszar systemu informacyjnego
danego obiektu, obsługiwany za pomocą
technicznych środków dostępnych w
informatyce.
Wyznaczniki jakości
systemu informatycznego:
zgodny z
wymaganiami użytkownika, niezawodny,
efektywny, łatwy w konserwacji,
interoperacyjny(jeżeli nie jest
autonomiczny), ergonomiczny.
31.Omów podstawowe diagramy
dynamiczne w języku IBM/Rational
UML.
Diagram przypadków użycia ( Use
Case Diagram)
Diagramy przypadków użycia opisują, co
robi system z punktu widzenia
zewnętrznego obserwatora. Eksponują to,
co robi system, a nie jak to robi. Diagramy
przypadków użycia pozostają w bliskim
związku ze scenariuszami. Przypadek
użycia to podsumowanie scenariuszy
pojedynczego zadania lub celu. Aktor to
ktoś albo coś, co inicjuje zdarzenia
związane z tym zadaniem. Aktor po prostu
określa rolę, którą odgrywa człowiek lub
obiekt. Jeden przypadek użycia może mieć
wielu aktorów. Diagramy przypadków
użycia mają trzy zastosowania: Określanie
funkcji (wymagań). Nowe przypadki użycia
często generują nowe wymagania, kiedy
system jest analizowany i projekt przybiera
coraz wyraźniejszy kształt. Komunikacja z
klientami. Prostota notacji sprawia, że
diagramy przypadków użycia są dobrym
sposobem porozumiewania się
programistów z klientami. Generowanie
przypadków testowych. Zbiór scenariuszy
danego przypadku użycia może
zasugerować sposoby testowania tych
scenariuszy.
Diagram stanów. (State Machine
Diagram)
Obiekty cechują się
zachowaniami i stanem. Stan obiektu
zależy od jego bieżącej aktywności lub
warunków. Diagram stanów pokazuje
możliwe stany obiektu oraz przejścia, które
powodują zmianę stanu. Stany to
zaokrąglone prostokąty. Przejścia to
strzałki wiodące od jednego stanu do
drugiego. Zdarzenia lub warunki
wyzwalające przejścia są zapisane obok
strzałek.
Diagram czynności (Activity Diagram)
to szczególny przypadek diagramu stanów,
który obrazuje strumień kolejno
wykonywanych czynności. Diagram
czynności obrazuje przepływ sterowania
25. Omów zakres fazy analizy w cyklu
wytwórczym systemów
informatycznych.
Celem fazy analizy jest ustalenie
wszystkich tych czynników, które mogą
wpłynąć na decyzje projektowe, na
przebieg procesu projektowego i na
realizację wymagań. Wynikiem jest
logiczny model systemu, opisujący sposób
realizacji przez system postawionych
wymagań, lecz abstrahujących od
szczegółów implementacyjnych.
Zakres
fazy analizy:
Wykracza poza zakres
odpowiedzialności systemu > kontekst
użycia i współpracy; Ujęcie w modelu
pewnych elementów nie będących częścią
systemu > model jest bardziej zrozumiały;
Abstrakcja modelowania > podczas
modelowania może nie być jasne, które
elementy modelu będą realizowane przez
oprogramowanie a które w sposób
sprzętowy lub ręcznie; Dostępne środki
mogą nie pozwolić na realizację systemu w
całości > analiza może wykryć fragmenty,
które mogą być szczególnie ważne;
28.Omów przykłady obiektowego
podejścia do analizy, projektu i
implementacji systemów
informatycznych.
Analiza i Projektowanie metody
obiektowe
Wspólna zasada: zaczynamy
od rozpoznania struktury obiektów.
Najważniejsze jest, czym są obiekty, a nie
co robią.
Wspólne kroki wszystkich metod
obiektowych:
Identyfikacja klas i obiektów, ich
atrybutów i metod
Ustalenie powiązań między obiektami
Ustalenie interfejsu każdego obiektu
(protokołu)
Ustalenie współpracy obiektów, przepływ
informacji
Implementacja, tworzenie prototypu.
# Przykład Metoda Coad/Yourdon
1. znajdowanie klas i obiektów
2.identyfikacja struktur 3. identyfikacja
tematów 4. definiowania atrybutów
5. definiowania usług
Model analizy obiektowej zawiera 5
warstw
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
26. Omów główne cechy modelu
analitycznego i podstawowe
czynności w fazie analizy systemu
informatycznego.
Cechy modelu analitycznego
:
(jest właściwie schematem blokowym).
Przedstawia sekwencyjne (ew.
współbieżne) kroki procesu
obliczeniowego. Diagram czynności
zawiera na ogół stany (akcji i czynności),
przejścia oraz obiekty. Wykonywane
obliczenia nazywamy stanami (akcji lub
czynności). Stany akcji i czynności są
szczególnymi przypadkami stanów
maszyny stanowej. Diagram czynności jest
rodzajem maszyny stanowej. Tory
wskazują umiejscowienie czynności.
Występując na diagramie czynności są
pooddzielane pionowymi, ciągłymi liniami.
Każdy tor ma unikatową nazwę.
Diagram sekwencji zdarzeń
(przebiegów)
Opisują one, jak obiekty
ze sobą współpracują. Diagram sekwencji
to diagram interakcji, który szczegółowo
pokazuje, w jaki sposób są wykonywane
operacje jakie komunikaty są wysyłane i
kiedy. Czas upływa w miarę poruszania się
w dół strony. Obiekty zaangażowane w
operację są wymienione od lewej do
prawej według tego, kiedy biorą udział w
sekwencji komunikatów.
Diagram współpracy (kooperacji)
Diagramy współpracy to diagramy
interakcji. Dostarczają tych samych
informacji co diagramy sekwencyjne, ale
skupiają się na rolach obiektów, a nie na
czasach przesyłania komunikatów. Na
diagramie sekwencyjnym role obiektów są
wierzchołkami, a komunikaty liniami
łączącymi wierzchołki. Prostokąty opisujące
rolę obiektu są oznaczone nazwami klas
lub obiektów (albo obiema nazwami).
Nazwy klas są poprzedzone dwukropkiem .
encjazwiązek, 2) podejście
obiektowe.
W analize i projektowaniu systemów inf.
rozróżniamy dwa podejścia – strukturalne i
obiektowe.
Podejście encjazwiązek jest
strukturalne – diagramy encjazwiązek
występuja w strukturalnej metodyce
SSADM. Model taki opisuje statyczna
strukturę systemu, grupując dane w
kolekcje zwane
obiektami (encje).
Graficznym odpowiednikiem jest diagram
ERD (ang. Entity Relationshi
Diagram),
którego węzły reprezentują obiekty
natomiast łuki odzwierciedlają relacje
pomiędzy obiektami. Przy podejściu
bazodanowym, gdy występuje spora ilość
danych, korzystne jest rozróżnianie
rodzajów danych oraz prześledzenie ich
przepływu.
Obecnie najbardziej
rozpowszechnione jest podejście
obiektowe. Cechuje się ono przejrzystością
oraz wygodą tworzenia modelów.
Intuicyjnie dokonywane jest powiązywanie
metod z danymi, na których one operują.
Pomiędzy obiektami można w prostszy
sposób zamodelować interakcję.
Model
obiektowy skupia się bardziej nad tym jak
dane są przetwarzane, jaki jest do nich
dostęp, jaka jest wymiana danych
pomiędzy obiektami. W modelu
obiektowym na drugi plan przesunięte jest
jak dane są przechowywane, a także jak są
reprezentowane. Znacznie istotniejsze jest
kto ma do nich dostęp, jakie obiekty biorą
udział w ich przetwarzaniu i jakie metody
operują na danych. Podejście to jest
korzystne dla wszystkich systemów, gdzie
konieczna jest odpowiednia kontrola
dostępu do danych, poprawności danych,
oraz kontrola sposobu przetwarzania.
36. Omów rodzaje testów
oprogramowania w odniesieniu do
cyklu życia systemu informatycznego.
Strategia procesu testowania zależy w
dużej mierze od przyjętego modelu cyklu
życia oprogramowania, rodzaju
oprogramowania, dojrzałości zespołu
testerów, posiadanych narzędzi do
testowania.
Badanie prognostyczne
– zanim
powstanie kod źródłowy, czyli w fazach:
określenia wymagań i projektowania.
Zalety
: Zwiększenie prawdopodobieństwa
uniknięcia lub zmniejszenia oddziaływania
zjawiska propagacji błędów
Stosunkowo niskie koszty testowania
Możliwość przebadania wielu różnych
projektów oprogramowania w celu wyboru
najlepszego do implementacji
Wady:
Bazowanie na modelu
oprogramowania, co może zmniejszyć
dokładność badania (potencjalna
rozbieżność z właściwościami
implementacyjnymi
Badania diagnostyczne:
Analiza dynamiczna
eksperymentowanie z działającym kodem
programu;
analiza statyczna
praca z kodem
źródłowym w celu:
rozpoznania funkcjonalności testowanego
kodu;
zaprojektowania odpowiednich testów;
inspekcje
audyty
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. wnĘtrze jest
niewidoczne. Przyczyna-skutek.
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.
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.
32.Omów podstawowe diagramy w
metodyce Oracle CASE Method.
Diagram zależności
Diagram zależnosci
to narzedzie do przedstawiania złożonych
zależnosci miedzy przyczynami i skutkami.
Diagramy zależnosci pozwalajż odnalećź
często trudną do wykrycia zależnosc
problemu od pierwotnej przyczyny.
Pomagaja zilustrowac łancuchy zaleznosci i
wzajemnych zaleznosci, przez co ułatwiaja
podjecie działania w odpowiednim miejscu.
Pomagaja równiez w identyfikacji efektów
ubocznych tych działan. Diagram
dokumentujący zależności między
elementami danych nazywa się diagramem
zależności lub diagramem determinowania.
●
Elementy danych rysowane są w postaci
owali, kółek lub baniek.
●
Zależność funkcyjna oznaczana jest przy
pomocy strzałek łączących element
determinujący z zależnym
Diagram zależności przedstawia kolejność
wykonywania wcześniej ustalonych funkcji
elementarnych. Dotyczy zależności
informacyjnych. Jest to tzw. diagram
następstw, uwzględniający zdarzenia
inicjujące wykonanie funkcji oraz ich
wyniki. Przedstawia wszystkie możliwe
drogi postępowania, zatem wymaga użycia
operatorów relacji OR, AND i XOR.
Diagram przepływu danych
DFD (ang.
Data Flow Diagram) . diagramy przepływu
danych pozwalają na modelowanie
procesów w systemie informatycznym lub
organizacji. Podstawowe elementy
diagramów DFD to:
proces
(ang. process),
przepływ
(ang. flow),
magazyn
inaczej
skład/składnica danyc
h (ang.
datastore),
terminator
(ang. terminator)
inaczej
jednostka zewnętrzna
(ang
external entity). Każdy z powyższych
elementów ma odpowiedni symbol
graficzny jednoznacznie wyróżniający go
na diagramie. Niestety, różne metodyki
używają różnej symboliki . zwykle jednak
koncepcja i semantyka diagramów jest
jednakowa.
Funkcje — (procesy) realizują określone
cele; jeśli funkcji nie można rozbić na pod
funkcje, wówczas nosi ona nazwę
elementarnej.
Magazyny danych — trwałe lub
tymczasowe składnice danych, które są
argumentami dla funkcji.
Terminatory — obiekty, które nie są
częścią systemu, ale stanowią odbiorców
bądź źródła danych lub argumentów
funkcji.
Przepływy — elementy pokazujące
kierunek przesyłu danych (np. bajtów,
znaków, pakietów..).
Diagram przepływu danych obrazuje za
pomocą przepływów kierunek przepływu
danych pomiędzy funkcjami, magazynami i
obiektami zewnętrznymi.
34. Omów zagadnienie audytu w
procesie wytwórczym systemów
informatycznych
Audytem nazywany jest niezależny
przegląd i ocenę jakości oprogramowania,
która zapewnia zgodność z wymaganiami
na oprogramowanie, a także ze
specyfikacją, generalnymi założeniami,
standardami, procedurami, instrukcjami,
kodami oraz kontraktowymi i licencyjnymi
wymaganiami.
Aby zapewnić obiektywność,
audyt powinien być przeprowadzony przez
osoby niezależne od zespołu projektowego.
Audyt powinien być przeprowadzany przez
odpowiednią organizację audytu (która
aktualnie formuje się w Polsce, Polskie
Stowarzyszenie Audytu) lub przez osoby
posiadające uprawnienia/licencję
audytorów. Reguły i zasady audytu są
określone w normie: ANSI/IEEE Std 1028
1988 „IEEE Standard for Reviews and
Audits”. Celem audytu projektu
informatycznego jest dostarczenie odbiorcy
i dostawcy obiektywnych, aktualnych i
syntetycznych informacji o stanie całego
projektu Pod kątem procesu wytwórczego
systemów informatycznych audytowi
podlegają produkty (cząstkowe) projektu
informatycznego. Ma to na celu
sprawdzenie czy rezultaty poszczególnych
prac odpowiadają zakładanym
wymaganiom.
39. Omów zagadnienie architektury
systemów informatycznych.
Architektura systemu
informatycznego jest
modelem systemu
uwzględniającym decyzje
analityka/projektanta dotyczące podziału
systemu na elementy składowe, wzajemne
relacje pomiędzy tymi elementami,
interakcje pomiędzy nimi, jak również ich
przeznaczenie. Często dla tego samego
systemu opisuje się
różne architektury
stanowiące różne i komplementarne punkty
jego widzenia, np.: architektura
przetwarzania danych, architektura
bezpieczeństwa systemu, architektura
sprzętowosystemowa, architektura
interoperacyjności, architektura warstw
systemu itd.
40.Omów zagadnienie projektowania
architektonicznego systemów
informatycznych.
Proces projektowania architektonicznego
polega na ustaleniu podstawowego zrębu
systemu. Podział architektoniczny jest
niezbędny do strukturalizacji i
porządkowania specyfikacji. Model
architektoniczny jest zwykle punktem
początkowym do specyfikowania
rozmaitych części systemu. Obejmuje
identyfikację najważniejszych
komponentów systemu i komunikacji
między nimi. Wyróżnia się składowe
procesy projektowania architektonicznego:
Strukturalizacja systemu
System jest dzielony na kilka
podstawowych podsystemów, przy czym
podsystem jest niezależną jednostką
oprogramowania
Identyfikuje się tu komunikację
między podsystemami
Modelowanie sterowania
Określa się ogólny model związków
sterowania między częściami systemu
Podział na moduły
Każdy zidentyfikowany podsystem jest
dzielony na moduły
Architekt musi wskazywać typy
modułów i ich połączenia
Wynikiem projektowania
architektonicznego są dokumentacja
zawierająca modele graficzne i opisy
tekstowe oraz modele przedstawiające
rozmaite perspektywy architektury.
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. 7291983] Dla procesów
wytwórczego może ona mieć "zbawienny"
wpływ gdyż poprawia ona proces
programowy. Czas wytworzenia systemu
dzięki inspekcji skraca się, gdyż wcześniej
dowiadujemy się o błędach. Zwiększa ona
także motywację pracowników poprzez
obudzenie w nich świadomości, że produkt
będzie oceniany. Może mieć ona z kolei
zgubny wpływ na etapie opracowywania
dokumentów, gdyż pracownikowi "rodzi
się" w głowie myśl: "inspekcja wskaże
błędy". Po inspekcji, kontrolach
indywidualnych i poprawie produktu
następuje burza mózgów mająca na celu
identyfikację przyczyn błędów (max 10
najpoważniejszych) i propozycji poprawy
procesu programowego, by błędy te nie
powtórzyły się w przyszłości. Idee są
notowane bez ich głębokiej oceny.
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 przeŚledziĆ wszystkie ŚcieŻki
przebiegu sterowania programu
wykonanie programu krok po kroku. Dane
testowe powinny byĆ dobrane tak, aby
kaŻda ŚcieŻka programiu była co najmniej
raz przetestowana. Tak okreŚla siĘ
sprawdzanie wewnĘtrznej logiki
oprogramowania. (Lepszym terminem
byłoby „
testowanie n/z szklanej skrzynki
”.)
Testowanie n/z białej skrzynki pozwala
sprawdziĆ wewnĘtrznĄ logikĘ programów
33.Porównaj następujące podejścia
do analizy i projektowania systemów
informatycznych: 1) podejście:
41.Omów istotę koncepcji wzorców
projektowych w projektowaniu
systemów informatycznych.
Wzorzec projektowy
jest to uniwersalne,
sprawdzone w praktyce rozwiązanie często
pojawiających się, powtarzalnych
problemów projektowych. Wzorce
projektowe zwiększają elastyczność,
wielokrotne wykorzystanie oraz czytelność
projektu, dostarczają sprawdzonych
rozwiązań dla powtarzających się
problemów, wpływają na sposób
modelowania, usprawniają komunikację
oraz tworzenie dokumentacji.
Podział wzorców 1:
Analityczne – ułatwiają modelowanie
dziedziny
Projektowe – opisują pewne techniki
projektowe
Architektury – standardowe rozwiązania
architektury
Organizacyjne – opisują organizację pracy
zespołu
Podział wzorców 2
:
Konstrukcyjne wykorzystywane do
pozyskiwania obiektów zamiast ich
bezpośredniego tworzenia
Strukturalne stosowane do łączenia
obiektów w większe struktury
Operacyjne definiowanie komunikacji
pomiędzy obiektami, kontrolowanie
przypływu danych w złożonych
algorytmach (programach), przydział
zobowiązań obiektom
Podział wzorców 3:
Warstwy prezentacji
Warstwy logiki
Warstwy integracji
45.Omów źródła kosztów
nieprawidłowości oprogramowania.
Koszty oprogramowania złej jakości( model
ISO 90041:1994)
Koszty jakości
koszty błędów (traktowane jako straty)
koszty oceny (traktowane jako nakłady)
koszty zapobiegania (traktowane jako
nakłady)
Koszty procesu
koszty niezgodności (traktowane jako
straty)
koszty zgodności (traktowane jako
nakłady)
Straty jakości
(skutki odchyleń od
wymagań jakościowych)
testowanie: 30%40% całkowitej
pracochłonności
testowanie systemów krytycznych: 70%
80% całkowitej pracochłonności
– Defekt nieprawidłowe działanie
człowieka w procesie wytwarzania,
np. złe sformułowanie wymagań, zła
decyzja projektowa, pomyłka w
implementacji, …;
– Błąd każde zdarzenie, w wyniku którego
kod produkuje nieoczekiwany rezultat;
– Awaria stan, w którym program nie jest
zdolny wykonać prawidłowo co najmniej
jednej ze swoich funkcji;
Pozwala na wykrycie nietestowanych
funkcjonalności oraz nadmiarowych testów
(nie testujących żadnej funkcjonalności).
49.Wymień i omów składowe jakości
oprogramowania na drugim poziomie
drzewa jakości.
Drugi poziom to: ADEKWATNOŚĆ:
Kompletność
Racjonalność funkcjonalna
Racjonalność komunikacyjna
Zwartość funkcjonalna
Zwartość komunikacyjna
54.Omów podstawowe schematy
testów integracyjnych. Podaj
przykłady.
Skokowe
grupują wybrane (lub
wszystkie) jednostki w celu ich
równoczesnego przetestowania
Przyrostowe
zakładają dołączenie do
tworzonej całości za każdym razem tylko
jednej uprzednio przetestowanej jednostki:
zstępujące
(odgórne) integruje się i
testuje się komponenty wysokiego poziomu
przed ukończeniem ich projektu i
implementacji;
wstępujące
(oddolne) testuje się i
integruje komponenty niskiego poziomu
przed ukończeniem budowy komponentów
wyższego poziomu;
Testowanie interfejsu jest wykonywane po
zintegrowaniu modułów lub podsystemów
w większe systemy.
Każdy moduł i podsystem ma
zdefiniowany interfejs, który jest
wywoływany przez inne komponenty
programu, np.:
Interfejsy parametryczne,
Interfejs w pamięci dzielonej,
Interfejsy proceduralne,
Interfejsy z przekazywaniem
komunikatów;
Celem testowania interfejsu jest wykrycie
usterek, które pojawiły się w systemie z
powodu błędów w interfejsach lub
nieprawdziwych założeniach o interfejsach.
46.Co to jest testowanie, weryfikacja
i walidacja oprogramowania? Podaj
przykłady.
Testowanie:
sprawdzanie, czy system
działa tak, jak założono w specyfikacji.
Przykłady:
–
Testowanie komponentów:
Testuje się
poszczególne komponenty, aby zapewnić,
że działają poprawnie;
–
Testowanie modułów
: Moduł jest kolekcją
niezależnych komponentów takich jak klasy
obiektów, abstrakcyjne typy danych, albo
bardziej luźną kolekcją procedur i funkcji;
–Testowanie podsystemów: Ta faza
obejmuje testowanie kolekcji modułów,
które zintegrowano w podsystemie;
–
Testowanie systemu
: Ten proces
testowania ma wykryć błędy wynikające z
nieprzewidzianych interakcji między
zintegrowanymi podsystemami i
problemów z interfejsami podsystemów;
–
Testowanie odbiorcze:
Jest to końcowa
faza procesu testowania przed przyjęciem
systemu do użytkowania;
Weryfikacja:
testowanie zgodności
systemu z wymaganiami zdefiniowanymi w
fazie określenia wymagań.
Walidacja (atestowanie):
ocena
systemu lub komponentu podczas lub na
końcu procesu jego rozwoju na zgodności z
wyspecyfikowanymi wymaganiami.
Atestowanie jest więc weryfikacją
końcową. Przykłady:
Przeglądy techniczne oraz inspekcje
oprogramowania.
Sprawdzanie czy wymagania na
oprogramowanie są zgodne z
wymaganiami użytkownika.
Sprawdzanie czy komponenty projektu są
zgodne z wymaganiami na
oprogramowanie.
Testowanie jednostek oprogramowania
(modułów).
Testowanie integracji oprogramowania,
testowanie systemu.
Testowanie akceptacji systemu przez
użytkowników
Audyt.
50. Omów główne klasy błędów w
systemach informatycznych
Klasa błędu :
Funkcjonalny Zła lub brakująca funkcja
Systemowy Błędnie użyte interfejsy, złe
zarządzanie zasobami, zły przepływ
sterowania
Przetwarzania Niewłaściwe przetwarzanie
danych w module
Danych Błędna specyfikacja, projekt,
rozmieszczenie lub inicjacja danych
Kodowania Niewłaściwe użycie instrukcji
języka programowania
Dokumentacyjny Niepełna lub błędna
treść dokumentacji
Inny Przyczyny nieznane
51.Omów czynności procesu
testowania oprogramowania.
1. Opracuj przypadki testowe
2. Przygotuj dane testowe
3. Uruchom program na danych testowych
4. Porównaj wyniki z przypadkami
testowymi
Testowanie komponentów <> Testowanie
modułów <> testowanie podsystemów <
> testowanie systemów <> testowanie
odbiorcze;
testowanie komponentów
: Testuje się
poszczególne komponenty, aby zapewnić,
że działają poprawnie
testowanie modułów
: Moduł jest kolekcją
niezależnych komponentów takich jak klasy
obiektów, abstrakcyjne typy danych, albo
bardziej luźną kolekcją procedur i funkcji.
testowanie podsystemów
: Ta faza
obejmuje testowanie kolekcji modułów,
które zintegrowano w podsystemie.
testowanie systemu
: Podsystemy
zintegrowano już w system. Ten proces
testowania ma wykryć błędy wynikające z
nie przewidzianych interakcji między
podsystemami i problemów z interfejsami
podsystemów.
testowanie odbiorcze
: Jest to końcowa
faza procesu testowania przed przyjęciem
systemu do użytkowania.
42.Omów wzorzec projektowy ……
(nazwa jednego z wzorców z
wykładu).
Jak wyżej
43.Omów model niezawodności
oprogramowania według Jelińskiego
Morandy.
wykrywanie błędów jest niezależne
usuwanie wykrytych błędów nie generuje
nowych
intensywność wykrywana błędów –
proporcjonalna do liczby błędów
pozostających w oprogramowaniu:
55.Jaka jest istota konstrukcyjnych
wzorców projektowych? Przedstaw
przykład wzorca konstrukcyjnego.
służą do pozyskiwania obiektów;
szczegółowo opisują jaki obiekt może
zostać stworzony;
uniezależniają kod od typów tworzonych
obiektów (zależne jest to tylko od
parametrów konfiguracyjnych);
Przykłady:
Singelton
Zapewnia powołanie tylko jednej instancji
obiektu w całej aplikacji i kontrolowany
dostęp;
Obiekt powołany wg tego wzorca jest
globalnym punktem dostępu do instancji
danej klasy ;
Wzorzec może być zmodyfikowany do
tworzenia określonej liczby instancji danej
klasy (>1);
Funkcje wzorca: utworzenie obiektu,
inicjalizacja obiektu, punkt dostępu,
modyfikacja obiektu;
Prostszym rozwiązaniem jest: globalnie
dostępna zmienna statyczną
przechowująca referencję do obiektu;
metoda fabrykująca;
Fabryka nie może przewidzieć, jakie
obiekty i w jaki sposób tworzyć;
Klient zna tylko interfejs klasy
abstrakcyjnej;
Informacje o sposobie i odpowiedzialność
za tworzenie obiektu znajdują się w
implementacjach „metody tworzącej” klas
pochodnych;
r(
) = E
/ I
-
C(
)
e
t
e
t
T
T
z(
)
gdzie: K – stała
Er – wspł. Pozostających
błędów
Et – stała – początkowa liczba błędów w
programie
It – stała – liczba instrukcji w programie
Ec – łączna unormowana liczba błędów
usuniętych w przedziale [0, (tał)] :)
t
) = K
e
R(
t
z(
)
K
t
52.Co to jest przypadek testowy,
scenariusz testów? Podaj przykłady.
Przypadek testowy (ang. test case)
specyfikacja:
stan początkowy, czyli stan testowanego
systemu (lub jego fragmentu) przed
testem,
dane wejściowe,
warunki testu,
dane wyjściowe (oczekiwane wyniki);
Jakość przypadku testowego:
prawdopodobieństwo znalezienia jeszcze
nie wykrytego błędu;
Test zakończony powodzeniem:
WYKRYWA dotychczas nie wykryty błąd;
[G. Myers, The Art. Of Software Testing,
1979]
Określone w rozporządzeniu ministra nauki
i informatyzacji z 19 października 2005:
przypadek testowy
— test akceptacyjny
obejmujący pojedynczy zestaw danych
wejściowych wprowadzanych do
oprogramowania testowanego;
scenariusz testowy
— zestaw co
najmniej dwóch przypadków testowych
powiązanych ze sobą w taki sposób, że
danymi wejściowymi do każdego kolejnego
przypadku testowego są niezmienione dane
wyjściowe z poprzedzającego go przypadku
testowego;
)
e
e
C(
t
47. Omów istotę i przykłady metod
prognostycznego badania jakości
oprogramowania.
Badanie prognostyczne
– nie ma kodu
źródłowego, „Zanim powstanie
implementacja oprogramowania, jego
przyszłe działanie jest badane na
podstawie założeń analitycznych/
projektowych [Bliźniuk, 2000]”
Główne zalety podejścia
prognostycznego:
• 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 podejścia prognostycznego:
• Bazowanie na modelu oprogramowania,
co może zmniejszyć dokładność badania
(potencjalna rozbieżność z właściwościami
implementacyjnymi).
E
44.Omów zjawisko propagacji
kosztów błędu oprogramowania i
podaj przykładowe szacunki kosztów.
Można tworzyć domyślny
produkt, ale też dać
użytkownikowi możliwość
podstawienia swojej
wyspecjalizowanej wersji;
fabryka abstrakcyjna;
fabryka;
Fabryka nowych obiektów w
zdefiniowanych klasach wzorcowych;
Wszystkie klasy wzorcowe mają metody o
tej samej nazwie, ale o innych realizacjach;
Zaleta – możliwość modyfikowania klas
wzorcowych (tworzących) w jednym
miejscu projektu;
Popularne wersje Fabryki: Metoda
Fabrykująca, Fabryka Abstrakcji,
Budowniczy, Prototyp;
budowniczy;
prototyp.
Podsumowanie:
Singleton – pojedyncza instancja obiektu;
Metoda Fabrykująca – tworzenie obiektów
w klasach pochodnych;
48. Omów istotę i przykłady metod
diagnostycznego badania jakości
oprogramowania.
Badanie diagnostyczn
e – istnieje kod
źródłowy.
Analiza dynamiczna
:
– eksperymentowanie z działającym kodem
programu;
Analiza statyczna:
– praca z kodem źródłowym w celu:
rozpoznania funkcjonalności
testowanego kodu;
zaprojektowania odpowiednich testów;
Testowanie wykrywa anomalie [J. Górski]:
53.Co to jest macierz przykrycia
testów akceptacyjnych? Podaj
przykłady.
Macierz przykrycia testów akceptacyjnych
jest to macierz opisująca wszystkie
funkcjonalności oprogramowania oraz
powiązane z nimi przypadki testowe.