io, 34-39


34. Omów zagadnienie audytu w procesie wytwórczym systemów informatycznych

Audytem nazywany jest niezależny przegląd i ocenę jakości oprogramowania, która zapewnia zgodność z wymaganiami na oprogramowanie, a także ze specyfikacją, generalnymi założeniami, standardami, procedurami, instrukcjami, kodami oraz kontraktowymi i licencyjnymi wymaganiami.

Aby zapewnić obiektywność, audyt powinien być przeprowadzony przez osoby niezależne od zespołu projektowego.

Audyt powinien być przeprowadzany przez odpowiednią organizację audytu (która aktualnie formuje się w Polsce, Polskie Stowarzyszenie Audytu) lub przez osoby posiadające uprawnienia/licencję audytorów.

Reguły i zasady audytu są określone w normie:

ANSI/IEEE Std 1028-1988 „IEEE Standard for Reviews and Audits”.

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

Pod kątem procesu wytwórczego systemów informatycznych audytowi podlegają produkty (cząśtkowe) projektu informatycznego. Ma to na celu sprawdzenie czy rezultaty poszczególnych prac odpowiadają zakładanym wymaganiom.

35.Omów zagadnienie inspekcji oprogramowania w procesie wytwórczym systemów informatycznych.

Inspekcja to formalna technika oceny, w której wymagania na oprogramowanie, projekt lub kod są szczegółowo badane przez osobę lub grupę osób nie będących autorami, w celu identyfikacji błędów, naruszenia standardów i innych problemów [IEEE Std. 729-1983]

Dla procesów wytwórczego może ona mieć "zbawienny" wpływ gdyż poprawia ona proces programowy.

Czas wytworzenia systemu dzięki inspekcji skraca się, gdyż wcześniej dowiadujemy się o błedach.

Zwiększa ona także motywację pracowników poprzez obudzenie w nich świadomości, że produkt będzie oceniany.

Może mieć ona z kolei zgubny wpływ na etapie opracowywania dokumentów, gdyż pracownikowi "rodzi się" w głowie myśl: "inspekcja wskaże błędy".

Po inspekcji, kontrolach indywidualnych i poprawie produktu następuje burza mózgów mająca

na celu identyfikację przyczyn błędów (max 10 najpoważniejszych) i propozycji poprawy procesu programowego, by błędy te nie powtórzyły się w przyszłości.

Idee są notowane bez ich głębokiej oceny.

36. Omów rodzaje testów oprogramowania w odniesieniu do cyklu życia systemu informatycznego.

Strategia procesu testowania zależy w dużej mierze od przyjętego modelu cyklu życia oprogramowania, rodzaju oprogramowania, dojrzałości zespołu testerów, posiadanych narzędzi do testowania.

Badanie prognostyczne - zanim powstanie kod źródłowy, czyli w fazach: określenia wymagań i projektowania.

Zalety:

- Zwiększenie prawdopodobieństwa uniknięcia lub zmniejszenia oddziaływania zjawiska propagacji błędów

- Stosunkowo niskie koszty testowania

- Możliwość przebadania wielu różnych projektów oprogramowania w celu wyboru najlepszego do implementacji

Wady:

- Bazowanie na modelu oprogramowania, co może zmniejszyć dokładność badania (potencjalna rozbieżność z właściwościami implemetacyjnymi

Badania diagnostyczne:

Typy:

- Analiza dynamiczna

- analiza statyczna

- inspekcje

- audyty

37.Omów uwarunkowania prawne i inżynierskie procesu testów akceptacyjnych systemu informatycznego.

Na podstawie art. 21 ust. 6 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. Nr 64, poz. 565) zarządza się, co następuje: § 1. Rozporządzenie określa: 1) metodykę , warunki i tryb sporządzania testów akceptacyjnych; 2) sposób postępowania w zakresie badania, o którym mowa w art. 21 ust. 1 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne, zwanego dalej „badaniem”, w tym sposób dokumentowania wyników badania oraz weryfikacji badania; § 3. 1. Podmiot publiczny sporządza testy akceptacyjne z zachowaniem metodyki prowadzenia projektów informatycznych o publicznym zastosowaniu odpowiadającej specyfice systemu teleinformatycznego używanego do realizacji zadań publicznych, w zakresie obejmującym wyłącznie funkcjonalność oprogramowania testowanego. 2. Sporządzenie testu akceptacyjnego obejmuje przygotowanie: 1) specyfikacji przypadku testowego, zgodnie z wzorem określonym w załączniku nr 1 do rozporządzenia; 2) specyfikacji scenariusza testowego, zgodnie z wzorem określonym w załączniku nr 2 do rozporządzenia, jeżeli jej sporządzenie jest niezbędne do przeprowadzenia badania z uwagi na funkcjonalność oprogramowania testowanego. § 4. 1. Podmiot publiczny, mając na uwadze, aby badanie obejmowało w pełni funkcjonalność oprogramowania testowanego: 1) sporządza opis badania składający się z: a) specyfikacji poszczególnych przypadków testowych, b) specyfikacji poszczególnych scenariuszy testowych w przypadku, o którym mowa w § 3 ust. 2 pkt 2; 2) zapewnia, nieodpłatnie dla podmiotów uprawnionych, dostęp do oprogramowania testowego albo, zgodnie z § 5 ust. 2, do oprogramowania komunikacyjnego; 3) publikuje, w Biuletynie Informacji Publicznej, opis badania, o którym mowa w pkt 1, oraz informacje niezbędne dla uzyskania skutecznego dostępu przez podmioty uprawnione do oprogramowania, o którym mowa w pkt 2.

38.Omów istotę testowania metodą black box i white box.

Testowanie strategią białej skrzynki pozwala sprawdzić wewnętrzną logikę programów poprzez odpowiedni dobór danych wejściowych, dzięki czemu można prześledzić wszystkie ścieżki przebiegu sterowania programu.

Tradycyjnie programiści wstawiają kod diagnostyczny do programu aby śledzić wewnętrzne przetwarzanie. Debuggery pozwalają programistom obserwować wykonanie programu krok po kroku.

Często niezbędne staje się wcześniejsze przygotowanie danych testowych lub specjalnych programów usprawniających testowanie (np. programu wywołującego testowaną procedurę z różnymi parametrami).

Dane testowe powinny być dobrane w taki sposób, aby każda ścieżka w programie była co najmniej raz przetestowana.

Ograniczeniem testowania na zasadzie białej skrzynki jest niemożliwość pokazania brakujących funkcji w programie. Wadę tę usuwa testowanie n/z czarnej skrzynki.

Przykładowy graf strumieni podprogramu wyszukującego binarnie:

0x01 graphic

Testowanie strategią czarnej skrzynki - Tak określa się sprawdzanie funkcji oprogramowania bez zaglądania do środka programu. Testujący traktuje sprawdzany moduł jak „czarną skrzynkę”, której wnętrze jest niewidoczne.

Testowanie n/z czarnej skrzynki powinno obejmować cały zakres danych wejściowych.

Testujący powinni podzielić dane wejściowe w „klasy równoważności”, co do których istnieje duże przypuszczenie, że będą produkować te same błędy. Np. jeżeli testujemy wartość „Malinowski”, to prawdopodobnie w tej samej klasie równoważności jest wartość „Kowalski”. Celem jest uniknięcie efektu „eksplozji danych testowych”.

„Klasy równoważności” mogą być również zależne od wyników zwracanych przez testowane funkcje. Np. jeżeli wejściem jest wiek pracownika i istnieje funkcja zwracająca wartości „młodociany”, „normalny” „wiek emerytalny”, wówczas implikuje to odpowiednie klasy równoważności dla danych wejściowych.

Wiele wejść dla danych (wiele parametrów funkcji) może wymagać zastosowania pewnych systematycznych metod określania ich kombinacji, np. tablic decyzyjnych lub grafów przyczyna-skutek.

0x01 graphic

Tester zadaje dane wejściowe i analizuje dane wyjściowe;

Zadaniem testera jest taki wybór danych wejściowych, aby z dużym p-stwem były elementami zbioru „Wejście-b”;

Dane wejściowe mogą być dzielone na klasy równoważności (dziedziny) o wspólnych cechach (np. liczby dodatnie);

39.Omów zagadnienie architektury systemów informatycznych.


Wyszukiwarka