— Wyjaśnić pojęcie „kombinatorycznej eksplozji danych testowych"?

W testach funkcjonalnych pełne przetestowanie rzeczywistego systemu jest praktycznie niemożliwe z powodu ogromnej liczby kombinacji danych wejściowych i stanów. Nawet dla stosunkowo małych programów ta liczba kombinacji jest tak ogromna, że pełne testowanie wszystkich przypadków musiałoby rozciągnąć się na miliardy lat.

Testy tylko dla jednej danej wejściowej muszą być przeprowadzone dl.a kilku wartości. Jeżeli takich danych jest wiele, to mamy do czynienia z kombinatoryczną eksplozję przypadków testowych.

— Omów działania jakie można podjąć w celu zapewnienia jakości oprogramowania.

Zapewnienie Jakości Oprogramowania (ZJO) - planowany i systematyczny wzorzec wszystkich działań potrzebnych dla dostarczenia adekwatnego potwierdzenia że element lub produkt jest zgodny z ustanowionymi wymaganiami technicznymi. Oznacza sprawdzanie: czy plany są zdefiniowane zgodnie ze standardami; czy procedury są wykonywane zgodnie z planami; czy produkty są implementowane zgodnie z planami.

— Porównaj testy strukturalne z testami funkcjonalnymi.

Dynamiczne testy zorientowane na wykrywanie błędów dzieli się na:

Testy funkcjonalne (functional tests, black-box tests), które zakładają znajomość jedynie wymagań

wobec testowanej funkcji. System jest traktowany jako czarna skrzynka, która w nieznany sposób

realizuje wykonywane funkcje.

Testy strukturalne (structural tests, white-box tests, glass-box tests), które zakładają znajomość

sposobu implementacji testowanych funkcji.

— Wyjaśnij pojęcie testów statycznych. Jakie błędy są przez nie wykrywane? Jaki rodzaj
testów statycznych jest szczególnie efektywny?

Testy statyczne - Analizują kod bez konieczności uruchomienia programu.

Dwie ogólnie stosowane techniki:

Dowody poprawności - nie są praktycznie możliwe dla rzeczywistych programów.

Metody nieformalne - polegają na analizie kodu przez programistów. Są niedocenione, chociaż

bardzo efektywne w praktyce.

Błędy wykrywane statycznie:

1. Niezainicjowane zmienne

2. Porównania na równość liczb zmiennoprzecinkowych

3. Indeksy wykraczające poza tablice

4. Błędne operacje na wskaźnikach

5. Błędy w warunkach instrukcji warunkowych

6. Niekończące się pętle

7. Błędy popełnione dla wartości granicznych (np. > zamiast >=)

8. Błędne użycie lub pominięcie nawiasów w złożonych wyrażeniach

9. Nieuwzględnienie błędnych danych

— Proszę wymienić (i w razie potrzeby opisać) najważniejsze zalety i wady relacyjnych baz danych.

Plusy:

wielodostęp

automatyczna weryfikacji więzów integralności

prawa dostępu dla poszczególnych użytkowników

wysoka niezawodność

rozszerzalność (ograniczona)

możliwość rozproszenia danych

dostęp na wysokim poziomie (SQL, ODBC, JDBC)

Minusy:

skomplikowane odwzorowanie modelu pojęciowego

mała efektywność dla pewnych zadań (kaskadowe złączenia)

ograniczenia w zakresie typów

brak hermetyzacji i innych cech obiektowości

zwiększenie długości kodu, który musi napisać programista

— Co to są i do czego służą narzędzia RAD? Proszę podać przykład takiego narzędzia.

RAD - Rapid Application Deveiopment

Terminem tym określa się narzędzia i techniki programowania umożliwiające szybką budowę

prototypów lub gotowych aplikacji, z reguły oparte o programowanie wizyjne. Termin RAD występuje

niekiedy jako synonim języków/środowisk czwartej generacji (4GL).

Przykładami narzędzi RAD są: Borland Delphi RAD Pack, IBM VisualAge (for Cobol, Java, C++,

Smalltalk), Microsoft Access Deyelopefs Toolkit, Microsoft Visual FoxPro Professional,

PowerBuilder Desktop, Power++ i wiele innych.

— Objaśnij, czego dotyczą wymagania funkcjonalne na system? Podaj kilka przykładowych.

Wymagania funkcjonalne - opisują funkcje wykonywane przez system. Określenie obejmuje następujące kwestie: określenie rodzaju użytkowników korzystających z systemu, określenie użytkowników niezbędnych do działania systemu, określenie sposobu korzystania, określenie systemów zewnętrznych wykorzystywanych do działania.

— Krótko scharakteryzuj różnicę w zadaniach stawianych przed fazą analizy i fazą
projektowania.

Zadania w fazie projektowania:

1. Uszczegółowienie wyników analizy.

2. Projektowanie składowych systemów nie związanych z dziedziną problemu;

3. Optymalizacja systemu;

4. Dostosowanie do ograniczeń i możliwości środowiska implementacji

5. Określenie fizycznej struktury systemu.

Celem fazy analizy jest ustalenie wszystkich tych czynników lub warunków w dziedzinie przedmiotowej, w otoczeniu realizatorów projektu, w istniejących lub planowanych systemach komputerowych, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na realizację wymagań.

W odróżnieniu, celem fazy projektowania jest udzielenie odpowiedzi na pytanie: Jak system ma być zaimplementowany? Wynikiem jest opis sposobu implementacji.

— Jakie elementy zasobów można pomierzyć, jakie ich cechy mogą być mierzalne

bezpośrednio? 4%. Z , 42 * S

Co mierzyć?

Proces.

Każde określone działanie w ramach projektu, wytwarzania lub eksploatacji oprogramowania.

Produkt.

Każdy przedmiot powstały w wyniku procesu: kod źródłowy, specyfikację projektową

udokumentowaną modyfikację, plan testów, dokumentację, itd.

Zasób.

Jest to każdy element niezbędny do realizacji jakiegoś procesu, są to na przykład: osoby, narzędzia,

metody wytwarzania, itd.

Bezpośrednio można zmierzyć np.

sprzęt - cena, szybkość, wielkość pamięci...

biuro - można zmierzyć wielkość, jakość oświetlenia, temperaturę....

oprogramowanie: cena, wielkość, stopień złożoności...

— Omów, jaki jest cel zarządzania konfiguracją oprogramowania.

Celem zarządzania konfiguracją oprogramowania jest planowanie, organizowanie, siei uwcai no i

koordynowanie działań mających na celu identyfikację, przechowywanie i zmiany oprogramowania w

trakcie jego rozwoju, integracji i przekazania do użycia.

Każdy projekt musi podlegać konfiguracji oprogramowania. Ma ono krytyczny wpływ na jakość

końcowego produktu. Jest niezbędne dla efektywnego rozwoju oprogramowania i jego późniejszej

pielęgnacyjności.

— Co jest podstawowym powodem kryzysu oprogramowania? Jakie stosuje się środki dla przezwyciężenia kryzysu oprogramowania?

Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania. Środki zaradcze:

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

2. Zasada abstrakcji - eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego
   przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego
   zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy.

3. Zasada ponownego użycia - wykorzystanie wcześniej wytworzonych schematów, metod, wzorców,
   komponentów projektu, komponentów oprogramowania, itd.

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

— Na co należy zwrócić uwagę w kwestii współpracy z klientem podczas fazy strategicznej?

Ważnym elementem fazy strategicznej jest jasne określenie celów przedsięwzięcia z punktu widzenia klienta. Nie zawsze są one oczywiste, co często powoduje nieporozumienia pomiędzy klientem i wykonawcą. Równie ważne jest określenie ograniczeń klienta (np. finansowych, infrastruktury, zasobów ludzkich, czasu wdrożenia, itd.)

— Omów koncepcję „zarządzania przez jakość" (TQM). '/./ I_Ą

TQM - zarządzanie przez jakość - Koncepcja wymyślona przez Japończyka Eiji Toyodę dla potrzeb naprawy japońskiego przemysłu motoryzacyjnego. Należy tak sterować wszystkimi fazami procesu produkcyjnego wyrobu, aby klient był zadowolony z jakości tego wyrobu.

— Na czym polega i do czego służy technika posiewania błędów? ^0\ /"^

Technika "posiewania błędów" polega na tym, że do programu celowo wprowadza się pewną liczbę błędów podobnych do tych, które występują w programie. Wykryciem tych błędów zajmuje się inna grupa programistów niż ta, która dokonała "posiania" błędów. Technika ta pozwala również na przetestowanie skuteczności metod testowania.

— Na co należy zwrócić uwagę przy tworzeniu i testowaniu modułów o szczególnym
znaczeniu dla bezpieczeństwa systemu? ^^' &O

Wymagania wobec systemu mogą być niepełne i nie opisywać zachowania systemu we wszystkich

sytuacjach. Dotyczy to zwłaszcza sytuacji wyjątkowych, np. wprowadzenia niepoprawnych danych.

Ważne jest, aby system zachował się bezpiecznie wtedy, gdy właściwy sposób reakcji nie został

opisany.

Niebezpieczeństwo może także wynikać z awarii sprzętowych. Analiza bezpieczeństwa musi

uwzględniać oba czynniki.

— Na czym polega „zasada spójności" przy projektowaniu interfejsu użytkownika? ^"\

Spójność projektu oznacza semantyczną zgodność wszystkich informacji zawartych na poszczególnych diagramach i w specyfikacji. Spójność opisuje na ile poszczególne części projektu pasują do siebie. Kryteria podziału projektu (i rodzaje spójności):

1. Podział przypadkowy. Podział na moduły (części) wynika wyłącznie z tego, że całość jest za duża (utrudnia wydruk, edycję, itd) 2. Podział logiczny. Poszczególne składowe wykonują podobne funkcje, np. obsługa błędów, wykonywanie podobnych obliczenuś^Podźiał czasowy. Składowe są uruchamiane w podobnym czasie, np. podczas startbnlub zaj0nczenia pracy systemu. 4. Podział proceduralny (sekwencyjny). Składowe są kolejno uruc^ajrilane. Dane wyjściowe jednej składowej stanowią wejście innej 5. Podział komunikacyjny. SkłactóWe działają na tym samym zbiorze danych wejściowych i wspólnie produkują zestaw danycl>)^jsciow^h 6. Podział funkqonalny. Wszystkie składowe są niezbędne dla realizacji jednej tg

Czy opcjonalność cyklicznych związków agregacji jest jednym z warunków koniecznych

do tego, aby diagram klas był poprawny (i sensowny)? Odpowiedź proszę uzasadnić.

Tak, jest to warunek konieczny. Czemu? Nie wiem. Wykład 6, slajd 15 fi /^~*

— Objaśnij, czego dotyczą wymagania niefunkcjonalne na system? Podaj kilka
przykładowych.

Wymagania niefunkcjonalne opisują ograniczenia, przy których system ma realizować swoje funkcje.

1. Wymagania dotyczące produktu. (Np. musi istnieć możliwość operowania z systemem wyłącznie '
   za pomocą klawiatury.)

2. Wymagania dotyczące procesu. (Np. proces realizaqi harmonogramowania zleceń musi być
   zgodny ze standardem opisanym w dokumencie XXXA/96).

3. Wymagania zewnętrzne. (Np. system harmonogramowania musi współpracować z bazą danych
   systemu komputerowego działu marketingu opisaną w dokumencie YYYB/95. Niedopuszczalne są
   jakiekolwiek zmiany w strukturze tej bazy.)

— Zdefiniuj pojęcie metodyka i objaśnij dlaczego stosowanie metodyk w procesie konstrukcji
Sl jest korzystne.

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 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 do następnej fazy,

notacje których należy używać oraz dokumentaqę powstającą w każdej z faz.

Notacja jest ściśle powiązana z metodyką służy do dokumentowania wyników faz projektu, jako

środek wspomagający ludzką pamięć i wyobraźnię, oraz jako środek komunikacji w zespołach oraz

pomiędzy projektantami i klientami.

— Omów, na czym polega metoda COCOMO i z jakich danych wejściowych korzysta się w tej

metodzie. 'ti.M^ltf, 4Zlh 12_t /Q

COCOMO jest oparte na kilku formułach pozwalających oszacować całkowity koszt przedsięwzięcia

na podstawie oszacowanej liczby linii kodu.

COCOMO wymaga oszacowania liczby instrukcji, z których będzie składał się system. Rozważane

przedsięwzięcie jest następnie zaliczane do jednej z klas:

1. Przedsięwzięć łatwych (organicznych, organie). Klasa ta obejmuje przedsięwzięcia wykonywane
   przez stosunkowo małe zespoły, złożone z osób o podobnych wysokich kwalifikacjach. Dziedzina jest
   dobrze znana. Przedsięwzięcie jest wykonywane przy pomocy dobrze znanych metod i narzędzi.

2. Przedsięwzięć niełatwych (pół-oderwanych, semi-detached). Członkowie zespołu różnią się
   stopniem zaawansowania. Pewne aspekty dziedziny problemu nie są dobrze znane.

3. Przedsięwzięć trudnych (osadzonych, embedded). Obejmują przedsięwzięcia realizujące systemy
   o bardzo złożonych wymaganiach. Dziedzina problemu, stosowane narzędzia i metody są w dużej
   mierze nieznane. Większość członków zespołu nie ma doświadczenia w realizacji podobnych zadań.

Dane z których korzysta - na przykład wyznacza poziom złożoności oprogramowania jako funkcję linii kodu źródłowego, co dla różnych języków programowania jest inne.

— Przedstaw zasady (sposoby) walki ze złożonością w oprogramowaniu.

1. Stosowanie technik i narzędzi ułatwiających pracę nad złożonymi systemami;

2. Korzystanie z metod wspomagających analizę nieznanych problemów oraz ułatwiających
   wykorzystanie wcześniejszych doświadczeń;

3. Usystematyzowanie procesu wytwarzania oprogramowania, tak aby ułatwić jego planowanie i
   monitorowanie;

4. Wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu wysokiej
   jakości jest zadaniem wymagającym profesjonalnego podejścia.

Zasady:

1. Zasada dekompozycji:

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

2. Zasada abstrakcji:

eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy.

3. Zasada ponownego użycia:

wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu,

komponentów oprogramowania, itd.

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

— Wyjaśnij pojęcia zakresu i kontekstu przedsięwzięcia informatycznego.

Zakres przedsięwzięcia: określenie fragmentu procesów informacyjnych zachodzących w organizacji, które będą objęte przedsięwzięciem. Na tym etapie może nie być jasne, które funkcje będą wykonywane przez oprogramowanie, a które przez personel, inne systemy lub standardowe wyposażenie sprzętu.

Kontekst przedsięwzięcia: systemy, organizacje, użytkownicy zewnętrzni, z którymi tworzony system ma współpracować.

— Porównaj metodę testowania strukturalnego i testowania z użyciem statycznych metod
nieformalnych.

Która z tych metod w Twojej ocenie lepiej nadaje się do automatyzacji?

Testy strukturalne (structural tests, white-box tests, g!ass-box tests), zakładają znajomość sposobu

implementacji testowanych funkcji.

Testy statyczne polegają na analizie kodu bez uruchomienia programu.

Metody nieformalne - polegają na analizie kodu przez programistów. Są niedocenione, chociaż

bardzo efektywne w praktyce.

— Co to jest „plan zapewnienia jakości oprogramowania" (PZJO)?

Plan zapewnienia jakości oprogramowania (PZJO) - powinien być sporządzany i modyfikowany przez cały okres życia oprogramowania. Powinien ustalać i opisywać wszelkie aktywności związane z zapewnieniem jakości dla całego projektu.

Odpowiednie sekcje planu jakości powinny dotyczyć wszystkich ustalonych w danym modelu rozwoju oprogramowania faz cyklu życia oprogramowania.

— Jakie problemy mogą wyniknąć podczas stosowania testów funkcjonalnych?

Testy funkcjonalne (functional tests, black-box tests), które zakładają znajomość jedynie wymagań wobec testowanej funkcji. System jest traktowany jako czarna skrzynka, która w nieznany sposób

realizuje wykonywane funkcje. Testy powinny wykonywać osoby, które nie były zaangażowane w

realizację testowanych fragmentów systemu.

W testach funcjonalnych pełne przetestowanie rzeczywistego systemu jest praktycznie niemożliwe z

powodu ogromnej liczby kombinacji danych wejściowych i stanów. Nawet dla stosunkowo małych

programów ta liczba kombinacji jest tak ogromna, że pełne testowanie wszystkich przypadków

musiałoby rozciągnąć się na miliardy lat.

Testy tylko dla jednej danej wejściowej muszą być przeprowadzone dla kilku wartości. Jeżeli takich

danych jest wiele, to mamy do czynienia z kombinatoryczną eksplozję przypadków testowych.

— Co oznacza termin „mocna kontrola typu"?

Typ jest wyrażeniem (oraz pewną abstrakcją programistyczną) przypisaną do pewnych bytów programistycznych, np. zmiennej, danej. Specyfikuje rodzaj wartości, które może przybierać byt programistyczny, lub „zewnętrzne" cechy tego bytu (interfejs). Jest formalnym ograniczeniem narzuconym na budowę zmiennych lub obiektów. Typy określają również parametry i wyniki procedur, funkcji i metod.

Zasadniczym celem typów jest kontrola formalnej poprawności programu.

W językach z tzw. mocnym typowaniem (strong typing), np. Pascalu i Modula-2, każdy deklarowany byt programistyczny musi być obowiązkowo wyposażony w deklaraqę typu. Poprzez tę deklarację programista wyraża swoje oczekiwania co do roli tego bytu w programie. Te oczekiwania są następnie sprawdzane.

— Czy acykliczność związków generalizacji/specjalizacji jest warunkiem koniecznym do tego,
aby diagram klas poprawny (i sensowny)? Odpowiedź proszę uzasadnić.

Tak, jest to warunek konieczny. Czemu? Nie wiem. Wykład 6, slajd 15

— Co może stanowić źródło informacji przy tworzeniu wymagań na system? >. 2S

Wymagania na system są formułowane w pewnym formalnym języku, następnie poddawane są kolejnym transformacjom, aż do uzyskania działającego kodu. Mogą to być wymagania funkcjonalne, które opisują funkcje wykonywane przez system. Określenie obejmuje następujące kwestie: określenie rodzaju użytkowników korzystających z systemu, określenie użytkowników niezbędnych do działania systemu, określenie sposobu korzystania, określenie systemów zewnętrznych wykorzystywanych do działania.

— Co jest efektem fazy analizy: jakie modele? jakie powiązane z nimi diagramy?

Celem fazy analizy jest ustalenie wszystkich tych czynników lub warunków w dziedzinie przedmiotowej, w otoczeniu realizatorów projektu, w istniejących lub planowanych systemach komputerowych, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na realizację wymagań. Wynikiem jest

Logiczny (analityczny) model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujących od szczegółów implementacyjnych. Z reguły wykracza poza zakres odpowiedzialności systemu Powiązane diagramy:

1. diagram klas

2. diagram przypadków użycia

3. diagramy sekwencji komunikatów (dla wybranych sytuacji)

4. diagramy stanów (dla wybranych sytuacji)

— Czym różni się metryka od pomiaru ? Wyjaśnij oba pojęcia.

Pomiar (measurement) jest to proces, w którym atrybutom świata rzeczywistego przydzielane są liczby lub symbole w taki sposób, aby charakteryzować te atrybuty według jasno określonych zasad. Jednostki przydzielane atrybutom nazywane są miarą danego atrybutu.

Metryka (metric) jest to proponowana (postulowana) miara. Nie zawsze charakteryzuje ona w sposób obiektywny dany atrybut. Np. ilość linii kodu (LOC) jest metryką charakteryzującą atrybut "długość

programu źródłowego", ale nie jest miarą ani złożoności ani rozmiaru programu (choć występuje w tej roli).

— Wymień elementy projektu i oprogramowania, które powinny być przedmiotem zarządzania
konfiguracją oprogramowania.

Wszystkie elementy projektu i oprogramowania muszą być przedmiotem ZKO, w szczególności:

1. dokumentacja: wymagań, analityczna, projektowa, testowania, użytkownika, itd.

2. moduły z kodem źródłowym, kody do konsolidowania, kody binarne,

3. ekrany interfejsu użytkownika,

4. pliki z danymi tekstowymi (np. komunikatami systemu), bazy danych, słowniki, itd.

5. kompilatory, konsolidatory, interpretery, biblioteki, protokoły, narzędzia CASE, konfiguracje
   sprzętowe, itd.

6. oprogramowanie testujące, dane testujące,

7. serwery WWW wraz z odpowiednimi stronami HTML i oprogramowaniem,

— Co to jest metodyka (lub metodologia) i co ona definiuje?

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 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 do następnej fazy,

notacje których należy używać oraz dokumentację powstającą w każdej z faz.

— Opisz metodę szacowania kosztów COCOMO.

Metoda szacowania kosztów COCOMO (COnstructive COst MOdel) - Wymaga oszacowania liczby instrukcji, z których będzie składał się system. Rozważane przedsięwzięcie jest następnie zaliczane do jednej z klas:

1. Przedsięwzięć łatwych (organicznych, organie). Klasa ta obejmuje przedsięwzięcia wykonywane
   przez stosunkowo małe zespoły, złożone z osób o podobnych wysokich kwalifikacjach. Dziedzina jest
   dobrze znana. Przedsięwzięcie jest wykonywane przy pomocy dobrze znanych metod i narzędzi;

2. Przedsięwzięć niełatwych (pół-oderwanych, semi-detached). Członkowie zespołu różnią się
   stopniem zaawansowania. Pewne aspekty dziedziny problemu nie są dobrze znane.

3. Przedsięwzięć trudnych (osadzonych, embedded). Obejmują przedsięwzięcia realizujące systemy
   o bardzo złożonych wymaganiach. Dziedzina problemu, stosowane narzędzia i metody są w dużej
   mierze nieznane. Większość członków zespołu nie ma doświadczenia w realizacji podobnych zadań.
   Metoda COCOMO zakłada, że znając nakład można oszacować czas realizacji przedsięwzięcia, z
   czego wynika przybliżona wielkość zespołu.

— Opisz technikę posiewania błędów. Jakie są zasadnicze cele jej stosowania?

Technika "posiewania błędów" polega na tym, że do programu celowo wprowadza się pewną liczbę błędów podobnych do tych, które występują w programie. Wykryciem tych błędów zajmuje się inna grupa programistów niż ta, która dokonała "posiania" błędów. Technika ta pozwala również na przetestowanie skuteczności metod testowania.

— Wymień zasady zarządzania jakością.

Zasady zarządzania jakością:

1. Ukierunkowanie na klienta

2. Przywództwo

3. Zaangażowanie ludzi

4. Podejście procesowe

1. Podejście systemowe

2. Ciągłe doskonalenie

3. Rzetelna informacja

4. Partnerstwo dla jakości

— W jaki sposób testuje się programy zawierające iteracje? /?(% ^U

Testowanie programów zawierających pętle:

$ Kryteria doboru danych wejściowych mogą opierać się o następujące zalecenia: ^/l^.. Należy dobrać dane wejściowe tak, aby nie została wykonana żadna iteracja pętli, lub, jeżeli to ^ niemożliwe, została wykonana minimalna liczba iteracji.

^ #. Należy dobrać dane wejściowe tak, aby została wykonana maksymalna liczba iteracji. 3 4. Należy dobrać dane wejściowe tak, aby została wykonana przeciętna liczba iteracji.

— Jakie testy łatwo poddają się automatyzacji, a które bardzo trudno lub wcale? Odpowiedź
uzasadnij.

Testy statyczne bardzo łatwo można zautomatyzować, a co za tym idzie, Można wykonać dużą ich liczbę. Cyklicznie wykonuje sięnastępujące czynności:

1. Losowa konstrukcja danych wejściowych zgodnie z rozkładem prawdopodobieństwa tych danych

2. Określenie wyników poprawnego działania systemu na tych danych

3. Uruchomienie systemu oraz porównanie wyników jego działania z poprawnymi wynikami.
   Technika ta jest jednak mało efektywna.

Testowanie wstępujące: najpierw testowane są pojedyncze moduły, następnie moduły coraz wyższego poziomu, aż do osiągnięcia poziomu całego systemu. Zautomatyzowanie tej metody nie zawsze jest możliwe, gdyż często moduły są od siebie zależne.

Testy nieformalne polegają na analizie kodu przez programistów. Jeśli błąd zostanie wykryty, od razu jest poprawiany i nie ma tutaj możliwości zautomatyzowania działań.

— Na czym polega niezgodność relacyjnego i obiektowego modelu danych?

RBD - W tej chwili są to najlepiej rozwinięte środowiska baz danych, pozwalające na

zaimplementowanie systemów bazujących na dużych zbiorach danych

Zaletą modelu obiektowego baz danych jest wyższy poziom abstrakcji, który umożliwia

zaprojektowanie i zaprogramowanie tej samej aplikacji w sposób bardziej skuteczny, konsekwentny i

jednorodny.

W stosunku do modelu relacyjnego, obiektowość wprowadza więcej pojęć, które wspomagają

procesy myślowe zachodzące przy projektowaniu i implementacji.

Sukces obiektowości w zakresie ideologii i koncepcji spowodował wprowadzenie wielu cech

obiektowości, takich jak klasy, metody, dziedziczenie, abstrakcyjne typy danych, do systemów

relacyjnych. „Częściowa obiektowość" jest wprowadzona do większości systemów relacyjnych

znajdujących się na rynku.

Takie podejście jest określane jako „hybrydowe" lub „obiektowo-relacyjne".

— Co to jest „transakcja" i jakie są jej podstawowe własności?

Transakcja to jednostka działalności systemu. Umożliwiają zachowanie spójności wielu jednocześnie

działających procesów. „Ręczna" synchronizaqa lub umawianie się są niepotrzebne.

Transakcje umożliwiają:

1 .Zachowanie spójności wielu jednocześnie działających procesów;

2.Uniknięcie niespójności danych i przetwarzania związanych z dowolnymi awariami sprzętu, błędami

w oprogramowaniu, itd;

3. Powrót do stanu sprzed rozpoczęcia jej działania po wystąpieniu dowolnego błędu. Jest to

podstawowa technika zwiększenia niezawodności oprogramowania działającego na bazie danych.

— Jaki model (i powiązane z nim diagramy) jest z powodzeniem wykorzystywany w procesie
definiowania wymagań na system?

Model analityczny (logiczny).

— Do czego wykorzystuje się metodę punktów funkcyjnych?

Metoda punktów funkcyjnych oszacowuje koszt projektu na podstawie funkcji użytkowych, które

system ma realizować. Stąd wynika, ze metoda ta może być stosowana dopiero wtedy, gdy funkcje

te są z grubsza znane.

Metoda jest oparta na zliczaniu ilości wejść i wyjść systemu, miejsc przechowywania danych i innych

kryteriów. Te dane są następnie mnożone przez zadane z góry wagi i sumowane. Rezultatem jest

liczba „punktów funkcyjnych".

Punkty funkcyjne mogą być następnie modyfikowane zależnie od dodatkowych czynników złożoności

oprogramowania.

Metoda jest szeroko stosowana i posiada stosunkowo mało wad.

Niemniej, istnieje wiele innych, mniej popularnych metod, posiadających swoich zwolenników.

Umożliwia ocenę złożoności oprogramowania wg pewnej skali:

1 FP - około 125 instrukcji w C

10 FPs - typowy mały program tworzony samodzielnie przez klienta (1 m-c)

100 FPs - większość popularnych aplikaqi; wartość typowa dla aplikacji tworzonych przez klienta

samodzielnie (6 m-cy)

1,000 FPs - komercyjne aplikacje w MS Windows, małe aplikacje klient-serwer (10 osób, ponad 12

m-cy)

10,000 FPs - systemy (100 osób, ponad 18 m-cy)

100,000 FPs - MS Windows'95, MVS, systemy militarne

— W jaki sposób zarządzający przedsięwzięciem programistycznym powinni stawić czoła
możliwym zagrożeniom?

1. Narzędzia do zarządzania projektem - istnieją rozliczne narzędzia i metody do planowania, analizy
   ryzyka, raportowania i wspomagania procesu wytwarzania (np. CASE)

2. Zagrożenia implementacyjne. Kierownik powinien rozumieć projekt od strony technicznej

3. Skomplikowanie - Stosować skojarzenia. Możliwość budowania skojarzeń jest cechą ludzkiego
   umysłu i znacznie wzmacnia zarówno objętość zapamiętywanej informacji jak i szybkość dostępu.

4. Groźba myślenia grupowego które jest zwykle bezkrytyczne - należy tworzyć sesje krytycyzmu

5. Ergonomia pracy - lepiej pracuje się w mniejszych pomieszczeniach niż w wielkich halach.

— Scharakteryzuj model kaskadowy cyklu życiowego oprogramowania. Wskaż jego zaiety i
wady.

Model kaskadowy cyklu życia oprogramowania - pomaga w harmonogramowaniu prac nad

projektem.

Wady:

1. narzucanie twórcom oprogramowania ścisłej kolejności wykonywania prac,

2. wysoki koszt błędów we wczesnych fazach,

3. długa przerwa w kontaktach z klientami.
   Zalety:

1. jest on do pewnego stopnia niezbędny dla planowania, harmonogramowania, monitorowania i
   rozliczeń finansowych.

2. Możliwość realizaqi dalszych faz przez inną firmę:

— Opisz metodę analizy punktów funkcyjnych (Function Point Analysis).

Metoda punktów funkcyjnych oszacowuje koszt projektu na podstawie funkqi użytkowych, które system ma realizować. Stąd wynika, ze metoda ta może być stosowana dopiero wtedy, gdy funkcje te są z grubsza znane.

Metoda jest oparta na zliczaniu ilości wejść i wyjść systemu, miejsc przechowywania danych i innych kryteriów. Te dane są następnie mnożone przez zadane z góry wagi i sumowane. Rezultatem jest liczba „punktów funkcyjnych".

Punkty funkcyjne mogą być następnie modyfikowane zależnie od dodatkowych czynników złożoności

oprogramowania.

Metoda jest szeroko stosowana i posiada stosunkowo mało wad.

Niemniej, istnieje wiele innych, mniej popularnych metod, posiadających swoich zwolenników.

Kolejność obliczeń Punktów Funkcyjnych

1. Identyfikacja systemu

2. Obliczenie współczynnika korygującego

3. Wyznaczenie ilości zbiorów danych i ich złożoności

4. Wyznaczenie ilości i złożoności elementów funkcjonalnych (we, wy, zapytania)

5. Realizacja obliczeń

6. Weryfikacja

7. Raport, zebranie recenzujące

Jak ktoś lubi się katować - Dokładniejszy opis z całą masą pojebanych wzorów - Wykł. 12, folia 15-25

— Czy bezpieczeństwo oprogramowania to to samo co jego niezawodność? Odpowiedź
uzasadnić.

Bezpieczeństwo niekoniecznie jest pojęciem tożsamym z niezawodnością.

System zawodny może być bezpieczny, jeżeli skutki błędnych wykonań nie są groźne.

Wymagania wobec systemu mogą być niepełne i nie opisywać zachowania systemu we wszystkich

sytuacjach. Dotyczy to zwłaszcza sytuacji wyjątkowych, np. wprowadzenia niepoprawnych danych.

Ważne jest, aby system zachował się bezpiecznie także wtedy, gdy właściwy sposób reakcji nie

został opisany.

Niebezpieczeństwo może także wynikać z awarii sprzętowych. Analiza bezpieczeństwa musi

uwzględniać oba czynniki.

— Jakie mogą być czynniki ryzyka utraty jakości oprogramowania?

Najczęstszymi czynnikami ryzyka utraty jakości są:

nowość projektu,

złożoność projektu,

niedostateczne wyszkolenie personelu,

zbyt małe doświadczenie personelu,

niesformalizowane (tworzone i zarządzane ad hoc) procedury

niska dojrzałość organizacyjna wytwórcy.

— Omów co to jest audyt. Omów korzyści płynące z przeprowadzenia audytu.

Audytem nazywany jest niezależny przegląd i ocena 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. Korzyści:

1. Celem audytu projektu informatycznego jest dostarczenie odbiorcy i dostawcy obiektywnych,
   aktualnych i syntetycznych informacji o stanie całego projektu

2. Zebrane informacje służąjako podstawa do podejmowania strategicznych decyzji w projekcie

3. Ma na celu sprawdzenie czy wykonywane prace oraz sposób ich wykonywania są prawidłowe
   oraz czy rezultaty poszczególnych prac odpowiadają zakładanym wymaganiom

— Jakie testy zakładają znajomość sposobu implementacji testowanych funkcji? Omów ten
rodzaj testów.

Testy strukturalne (structural tests, white-box tests, glass-box tests), które zakładają znajomość

sposobu implementacji testowanych funkcji.

Dane wejściowe do tych testów dobiera się na podstawie analizy struktury programu realizującego

testowane funkcje.

Kryteria doboru danych testowych są następujące:

1. Kryterium pokrycia wszystkich instrukcji. Zgodnie z tym kryterium dane wejściowe należy dobierać
   tak, aby każda instrukcja została wykonana co najmniej raz. Spełnienie tego kryterium zwykle
   wymaga niewielkiej liczby testów.

2. Kryterium pokrycia instrukcji warunkowych. Dane wejściowe należy dobierać tak, aby każdy
   elementarny warunek instrukcji warunkowej został co najmniej raz spełniony i co najmniej raz nie
   spełniony. Testy należy wykonać także dla każdej wartości granicznej takiego warunku.

— Do czego służą narzędzia CASE? Jaka jest różnica pomiędzy narzędziami Upper-CASE, Lower-CASE i Integrated-CASE?

Narzędzia CASE - narzędzia wykorzystywane w trakcie prac nad oprogramowaniem, np. kompilatory,

debuggery itp.

1 .Wspomagają ogólnie rozumiane wytwarzanie oprogramowania;

2.Koncentrują się na fazach analizy i projektowania oraz bezpośrednim wykorzystaniu wyników tych

faz w implementacji.

Typy CASE:

1 .Upper-CASE: wspomaganie wczesnych faz prac nad oprogramowaniem, w szczególności fazy

analizy (potrzeby analityków i projektantów);

2.Lower-CASE: wspomaganie faz projektowania i implementacji (potrzeby programistów). Narzędzia

te są z reguły ściśle związane z konkretnym środowiskiem implementacji;

3. Integrated-CASE - połączenie obu powyższych.

— Dlaczego „dynamiczna alokacja pamięci" może być niebezpieczną techniką
programowania?

Dynamiczna alokacja pamięci bez zapewnienia automatycznego mechanizmu odzyskiwania nieużytków (garbage collection). Powoduje "wyciekanie pamięci" i w efekcie, coraz wolniejsze działanie i zawieszenie programu.

— Krótko scharakteryzuj kilka przykładowych czynników, które trzeba rozważać przy
konstruowaniu wymagań na system.

Wymagania na system są konstruowane w pewnym formalnym języku, potem poddawane są kolejnym transformacjom, aż do uzyskania działającego kodu. Są wykonywane bez udziału ludzi, ale nie sprawdziły się i nie są wykorzystywane. Czynniki:

1. Możliwości systemu: Zestaw funkcji, które ma wykonywać system, uporządkowany hierarchicznie.

2. Objętość: Ilu użytkowników będzie pracować jednocześnie? Ile terminali ma być podłączone do
   systemu? Ile czujników będzie kontrolowanych jednocześnie? Ile danych będzie przechowywane?

3. Szybkość: Jak długo może trwać operacja lub sekwencja operacji? Liczba operacji na jednostkę
   czasu. Średni czas niezbędny dla jednej operacji.

4. Dokładność: Określenie stopnia precyzji pomiarów lub przetwarzania. Określenie wymaganej
   dokładności wyników. Zastąpienie wyników ilościowych jakościowymi lub odwrotnie.

5. Ograniczenia: ograniczenia na interfejsy, jakość, skalę czasową sprzęt, oprogramowanie,
   skalowalność, itd.

6. Interfejsy komunikacyjne: sieć, protokoły, wydajność sieci, poziom abstrakcji protokołów
   komunikacyjnych, itd.

7; Interfejsy sprzętowe: specyfikacja wszystkich elementów sprzętowych, które będąskładały się na system, fizyczne ograniczenia (rozmiar, waga), wydajność (szybkość, RAM, dysk, inne pamięci), wymagania co do powierzchni lokalowych, wilgotnością temperatury i ciśnienia, itd.

8. Interfejsy oprogramowania: Określenie zgodności z innym oprogramowaniem, określenie
   systemów operacyjnych, języków programowania, kompilatorów, edytorów, systemów zarządzania
   bazą danych, itd.

9. Interakcja człowiek-maszyna: Wszystkie aspekty interfejsu użytkownika, rodzaj języka interakcji,
   rodzaj sprzętu (monitor, mysz, klawiatura), określenie formatów (układu raportów i ich zawartości),
   określenie komunikatów dla użytkowników (język, forma), pomocy, komunikatów o błędach, itd.

10. Adaptowalność: Określenie w jaki sposób będzie organizowana reakcja na zmiany wymagań:
dodanie nowej komendy, dodanie nowego okna interakcji, itd.

11. Bezpieczeństwo: założenia co do poufności, prywatności, integralności, odporności na hakerów,
    wirusy, wandalizm, sabotaż, itd.

12. Odporność na awarie: konsekwencje błędów w oprogramowaniu, przerwy w zasilaniu, kopie
    zabezpieczające, częstotliwości składowania, dzfennika zmian, itd.

13. Standardy: Określenie dokumentów standardyzacyjnych, które mają zastosowanie do systemu:
    formaty plików, normy czcionek, polonizacja, standardy procesów i produktów, itd.

14. Zasoby: Określenie ograniczeń finansowych, ludzkich i materiałowych.

15. Skala czasowa: ograniczenia na czas wykonania systemu, czas szkolenia, wdrażania, itd.

- Czego mogą dotyczyć metryki oprogramowania? Podaj przykłady.

Metryka (metric) jest to proponowana (postulowana) miara. Nie zawsze charakteryzuje ona w sposób obiektywny dany atrybut. Np. ilość linii kodu (LOC) jest metryką charakteryzującą atrybut "długość programu źródłowego", ale nie jest miarą ani złożoności ani rozmiaru programu (choć występuje w tej roli).

- Omów pojęcie wersja, związane z zarządzaniem konfiguracją oprogramowania.

Produkt oddany do eksploatacji musi podlegać zmianom. Każda modyfikacja oznacza powstanie

wersji systemu, mniej lub bardziej różnej od wersji poprzedniej. Niektórzy klienci mogą nie chcieć

zmiany oprogramowania, co implikuje istnienie wielu wersji produktu.

Inną przyczyną powstawania wersji jest zróżnicowanie potrzeb użytkowników. Np. mogą być wersje

będące kombinacją modułów oprogramowania. Jeszcze inną przyczyną jest istnienie wielu platform

sprzętowych i systemów operacyjnych.

System zarządzania wersjami zawiera:

• Informację o wszystkich wykonanych i oddanych do eksploatacji wersjach

• Informację o klientach, którzy nabyli daną wersję

• Wymagania sprzętowe i programowe poszczególnych wersji

• Informację o składowych (klasach, encjach, modułach) wchodzących w skład danej wersji

• Informację o żądaniach zmian w stosunku do danej wersji

• Informację o błędach wykrytych w poszczególnych wersjach.

- Na czym polega model spiralny cyklu życiowego oprogramowania. Omów model realizacji
przyrostowej systemu informatycznego.

Model spiralny cyklu życiowego oprogramowania polega na sekwencyjnej powtarzalności pewnych czynności, tj: Planowanie, analiza, konstrukq"a i atestowanie w celu zmniejszenia błędów zawartych w oprogramowaniu. Po wykonaniu części pracy wraca się do wcześniej wykonywanych, ale wykonuje na coraz większym produkcie.

Realizacja przyrostowa (odmiana modelu spiralnego) - Wybierany jest i realizowany podstawowy zestaw funkcji. Po realizacji pewnych funkcji następuje zrealizowanie i dostarczenie kolejnych funkcji. Wykład 1, folia 19-20.

- Na czym polega metoda Delphi szacowania pracochłonności projektu?

Metoda Delphi: zakłada zatrudnienie kilku niezależnych expertów, którzy nie komunikują się ze sobą i oddzielnie szacują koszty nakłady na podstawie własnych doświadczeń i metod. Koordynator zbiera ich wyniki, wylicza średnią i oddaje im z powrotem do poprawienia...

---Krótko omów najczęściej używane programy narzędziowe służące do testowania oprogramowania.

Programy porównujące - Są to narzędzia programistyczne umożliwiające porównanie dwóch programów, plików lub zbiorów danych celem wykrycia cech wspólnych i różnic. Często są niezbędne do porównania wyników testów z wynikami oczekiwanymi. Programy porównujące przekazują w czytelnej postaci różnice pomiędzy aktualnymi i oczekiwanymi danymi wyjściowymi. Ekranowe programy porównujące mogą być bardzo użyteczne dla testowania oprogramowania interakcyjnego. Są niezastąpionym środkiem dla testowania programów z graficznym interfejsem użytkownika.

Duża różnorodność narzędzi stosowanych w różnych fazach rozwoju oprogramowania. Np. wspomaganie do planowania testów, automatyczne zarządzania danymi wyjściowymi, automatyczna generacja raportów z testów, generowanie statystyk jakości i niezawodności, wspomaganie powtarzalności testów, itd.

— Na czym polegają trudności z oceną jakości oprogramowania?

1. Oceny jakości najczęściej muszą być znane zanim powstanie gotowy, działający produkt, co
   wyklucza zastosowanie obiektywnych metod pomiarowych.

2. Wiele czynników składających się na jakość produktu jest niemierzalna.

3. Produkty programistyczne są złożone i wieloaspektowe, co powoduje trudności w wyodrębnieniu
   cech mierzalnych, które odzwierciedlałyby istotne aspekty jakości.

4. Produkty programistyczne mogą działać w różnych zastosowaniach, o różnej skali. Pomiary
   jakości mogą okazać się nieadekwatne przy zmianie skali (np. zwiększonej liczbie danych lub
   użytkowników), w innym środowisku, itp.

5. Pomiary mogą okazać się bardzo kosztowne, czasochłonne lub niewykonalne (z powodu
   niemożliwości stworzenia środowiska pomiarowego przed wdrożeniem);

6. Nie ma zgody co do tego, w jaki sposób pomierzone cechy danego produktu składają się na
   syntetyczny wskaźnik jego jakości.

— Omów czynności wykonywane podczas przeprowadzania testów statystycznych.

1. śledzenie przebiegu programu (wykonywanie programu "w myśli" przez analizujące osoby)

2. wyszukiwanie typowych błędów:

— Co to jest inspekcja? Wymień i krótko omów co podlega inspekcji, jej zalety i wady?

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.

Cechy inspekcji:

1. Sesje są zaplanowane i przygotowane

2. Błędy i problemy są notowane

3.Wykonywana przez techników dla techników (bez udziału kierownictwa) 4. Dane nie są wykorzystywane do oceny pracowników 5.Zasoby na inspekcje są gwarantowane

6. Błędy są wykorzystywane w poprawie procesu programowego (prewencja)

7. Proces inspekcji jest mierzony i poprawiany

Korzyści inspekcji:

1 .Wzrost produktywności od 30% do 100%

2.Skrócenie czasu projektu od 10% do 30%

4. Skrócenie kosztu i czasu wykonywania testów od 5 do 10 razy

5.10 razy mniejsze koszty pielęgnacji naprawczej

6. Poprawa procesu programowego

/.Dostarczanie na czas (bo wcześnie wiemy o problemach)

8. Większy komfort pracy (brak presji czasu i nadgodzin)
9Zwięksźenie motywacji

10.Mniejsze koszty marketingu („przykrywanie" braku jakości)

Zagrożenia:

1 .Złe prowadzenie inspekcji - mała efektywność i skuteczność

2.Słabi kontrolerzy

3. Kontrola indywidualna niewystarczająca (jakość i ilość)

4. Skłonność autora do lekceważenia defektów na etapie opracowywania dokumentów

5. Dyskusje o rozwiązaniach podczas spotkania kontrolnego

3. Poczucie zagrożenia u autora - nieuzasadniona obrona własnych rozwiązań

4. Krytyczne nastawienie do autora

— Co oznacza termin „inżynieria odwrotna" (reverse engineering)? Gdzie ta technika może
być wykorzystywana?

Narzędzia inżynierii odwrotnej (reverse engineering) - są to narzędzia umożliwiające odtworzenie bardziej abstrakcyjnej postaci oprogramowania z postaci szczegółowej. Np. odtworzenie dokumentacji technicznej na podstawie kodu programu, odtworzenie źródłowego kodu programu na podstawie kodu skompilowanego (dekompilacja), odtworzeniu modelu logicznego bazy danych na podstawie jej fizycznej struktury, odtworzenie pojęciowego diagramu klas na podstawie deklaracji w języku programowania, itp.

— Proszę krótko scharakteryzować technikę o nazwie „tolerancja błędów".

Tolerancja błędów oznacza, że program działa poprawnie, a przynajmniej sensownie także wtedy,

kiedy zawiera błędy.

Tolerancja błędów oznacza wykonanie przez program następujących zadań.

1 .Wykrycia błędu;

2. Wyjścia z błędu, tj. poprawnego zakończenie pracy modułu, w którym wystąpił błąd;

3. Ewentualnej naprawy błędu, tj. zmiany programu tak, aby zlikwidować wykryty błąd.

— Jakie elementy (podstawowe; od strony merytorycznej) powinien zawierać dokument
będący efektem fazy zbierania i analizy wymagań?

Powinien zawierać:

1. Poprawiony dokument opisujący wymagania

2. Słownik danych zawierający specyfikację modelu

3. Dokument opisujący stworzony model, zawierający:

a. diagram klas

b. diagram przypadków użycia

c. diagramy sekwencji komunikatów (dla wybranych sytuacji)

d. diagramy stanów (dla wybranych sytuacji)

e. raport zawierający definicje i opisy klas, atrybutów, związków,
metod, itd.

4. Harmonogram fazy projektowania

5. Wstępne przypisanie ludzi i zespołów do zadań

— Objaśnij różnicę między metodyką a notacją. Jakie rodzaje metodyk są Ci znane?

• 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 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 do
  następnej fazy, notacje których należy używać oraz dokumentaqę powstającą w każdej z faz.

• Notacja jest ściśle powiązana z metodyką służy do dokumentowania wyników faz projektu, jako
  środek wspomagający ludzką pamięć i wyobraźnię, oraz jako środek komunikacji w zespołach oraz
  pomiędzy projektantami i klientami.

— Omów, na czym polega metoda punktów funkcyjnych i z jakich danych wejściowych
korzysta się w tej metodzie.

Metoda punktów funkcyjnych oszacowuje koszt projektu na podstawie funkqi użytkowych, które

system ma realizować. Stąd wynika, ze metoda ta może być stosowana dopiero wtedy, gdy funkcje

te są z grubsza znane.

Metoda jest oparta na zliczaniu iiości wejść i wyjść systemu, miejsc przechowywania danych i innych

kryteriów. Te dane są następnie mnożone przez zadane z góry wagi i sumowane. Rezultatem jest

liczba „punktów funkcyjnych".

Punkty funkcyjne mogą być następnie modyfikowane zależnie od dodatkowych czynników złożoności

oprogramowania.

Metoda jest szeToKo stosowana i posiaaa stosunKowo mato waa.

- Na czym polega zarządzanie ryzykiem i jak jest w tym rola kierownika projektu?

Podstawowe zadania kierownictwa przedsięwzięcia programistycznego:

• 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

- Przedstaw fazy realizacji systemu informatycznego opartej na prototypowaniu. W jakim
celu stosuje się taki model realizacji i jakie są jego zalety?

Prototypowanie: sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie

określania wymagań. Zalecany, gdy określenie początkowych wymagań jest stosunkowo łatwe.

Fazy: określenie wymagań, budowa prototypu, weryfikacja przez klienta, określenie wymagań,

realizacja w modelu kaskadowym.

Cele: wykrycie nieporozumień między klientem a twórcami systemu, wykrycie brakujących funkcji,

trudnych usług oraz braków w specyfikacji.

Zalety: możliwość demonstracji pracującej wersji systemu oraz możliwość szkoleń zanim zostanie

zbudowany system.

> — Na czym polega metoda analizy podziału aktywności (activity distribution analysis) w szacowaniu pracochłonności przedsięwzięcia?

Metoda analizy podziału aktywności (activity distribution analysis): Projekt dzieli się na aktywności, które są znane z poprzednich projektów. Następnie dla każdej z planowanych aktywność ustala się, na ile będzie ona bardziej (lub mniej) pracochłonna od aktywności już wykonanej, której koszt/nakład jest znany. Daje to szacunek dla każdej planowanej aktywności. Szacunki sumuje się dla uzyskania całościowego oszacowania.

- Jakie rodzaje zagrożeń mogą wystąpić w procesie zarządzania przedsięwzięciem
programistycznym?

1. Czynniki doświadczenia

• brak doświadczenia i/lub kwalifikacji kierownika projektu (niedoświadczony kierownik jest
  poważnym zagrożeniem dla projektu),

• brak doświadczenia i/lub kwalifikacji personelu (personel powinien być sprawdzony pod względem
  kwalifikacji, powinien być przypisany do odpowiednich zadań, ...)

• niedojrzałość dostawców (brak sukcesów w rozwijaniu podobnych projektów, brak standardów, brak
  certyfikatu ISO 9000, ...).

2. Czynniki planowania

• niedokładność metod szacowania czasu, kosztów, zasobów,

• zbyt krótka skala czasowa (niemożliwość zrównoleglenia pewnych prac),

• zbyt długa skala czasowa (zmiany wymagań, personelu, technologii),

• zależność od awarii losowych, wandalizmu i sabotażu (zniszczenie sprzętu, zniszczenie danych,
  itd.), _:

• zła lokalizacja personelu (utrudnienia w komunikaq"i),

• zła definicja odpowiedzialności (brak odpowiedzialnych za kluczowe zadania, wykonywanie
  niepotrzebnych lub drugorzędnych zadań, ...),

• częste zmiany personelu (nowy personel wymaga czasu dla zapoznania się z dotychczasowymi
  pracami).

3. Czynniki technologiczne

• nowość technologiczna (brak doświadczeń, konieczność dodatkowego wysiłku na rozpoznanie, ...),

• niedojrzałość lub nieodpowiedniość stosowanych metod (nowe metody są często niesprawdzone,
  konieczne jest praktyczne doświadczenie, ...),

• niedojrzałość lub nieodpowiedniość narzędzi (personę! powinien umieć je używać, mogą być
  nieodpowiednie w stosunku do metod, są zmieniane w trakcie projektu, ...},

• niska jakość użytego komercyjnego oprogramowania (może być przereklamowane, może nie być
  niezawodne, pielęgnowalne, bezpieczne, stabilne,...),

4. Czynniki zewnętrzne

• niska jakość lub niestabilność wymagań użytkownika,

• słabo zdefiniowane, niestabilne lub niestandardowe interfejsy zewnętrzne,

• niska jakość lub słaba dostępność systemów zewnętrznych (od których zależy powodzenie
  projektu; może być konieczne rozwijanie możliwości symulujących systemy zewnętrzne).

• Czy jedynym powodem określenia niezawodności oprogramowania jest zamieszczenie jej
  poziomu w wymaganiach klienta? Odpowiedź uzasadnić.

• Stosując jakie reguły można uzyskać 100% niezawodność oprogramowania, a jakie jedynie
  prowadzą do zwiększenia niezawodności.

• Wyjaśnij różnicę między schematem pojęciowym, a schematem logicznym.

• Objaśnij na przykładzie związek między pojęciami: dziedzina problemu i zakres
  odpowiedzialności systemu.

---