Systemy komputerowe - Funkcjonalność

Politechnika Wrocławska Wrocław 2007 Systemy komputerowe - Funkcjonalność ZESPÓŁ nr. 5 Rafał Bartoszewicz Krzysztof Diduch Kinga Frączyk Joanna MroŜek Artur Pęczak

SPIS TREŚCI 1. Wstęp... 4 1.1. Ewolucja podejścia 4 1.2. Etapy tworzenia oprogramowania 5 1.3. Audyt funkcjonalności systemu 6 1.3.1. Cel...6 1.3.2. Etapy przeprowadzania audytu funkcjonalności systemu informatycznego...6 2. Funkcjonalność... 7 2.1. Definicje funkcjonalności 7 I. Funkcjonalność wg ISO 9126. ODPOWIEDNIOŚĆ... 8 I.1. Mierniki zewnętrzne 8 I.1.1 Funkcjonalna adekwatność...8 I.1.2. Kompletność implementacji funkcjonalnej....8 I.2. Mierniki wewnętrzne 9 I.2.1. Funkcjonalna adekwatność...9 I.2.2. Kompletność implementacji funkcjonalnej....9 II. Funkcjonalność wg ISO 9126. DOKŁADNOŚĆ... 11 II.1. Mierniki zewnętrzne 11 2.1.1. Oczekiwana dokładność...11 2.1.2. Dokładność obliczeniowa...12 2.1.3. Precyzja...12 II.2. Mierniki wewnętrzne 13 2.2.1. Dokładność obliczeniowa...13 3.2.2 Precyzja...13 III. Funkcjonalność wg ISO 9126. WSPÓŁDZIAŁANIE... 15 III.1. Mierniki zewnętrzne 15 3.1.1. Kompatybilność...15 3.1.2. Środowisko programowe...15 3.1.3. Współdziałanie techniczne...15 III.2. Mierniki wewnętrzne 15 3.2.1. Formaty danych...15 3.2.2. Preferencje uŝytkownika...16 3.2.3. Formaty protokołów...16 V. Funkcjonalność wg ISO 9126. BEZPIECZEŃSTWO... 18 IV.1. Mierniki zewnętrzne 18 4.1.1. Audyt dostępu...18 4.1.2. Kontrola dostępu...18 4.1.3. Zapobieganie utracie danych...19 IV.2. Mierniki wewnętrzne 20 4.2.1. Audyt dostępu...20 4.2.2. Kontrola dostępu...20 4.2.3. Zapobieganie utracie danych...20 4.2.4. Szyfrowanie danych...21 4.2.5. Zgodność funkcjonalna...21 V. Funkcjonalność wg ISO 9126. ZGODNOŚĆ... 24 V.1. Mierniki zewnętrzne 24 5.1.1. Zgodność funkcjonalna...24 5.1.2. Standardy zgodności interfejsów...25 V.2. Mierniki wewnętrzne 25 Politechnika Wrocławska, Wrocław 2007 2

5.2.1. Zgodność funkcjonalna...26 5.2.2. Wewnątrz systemowe standardy zgodności...26 VI. Funkcjonalność wg ISO 9126 - Metoda UMEWAP... 29 VI.1. Opis metody 29 VI.2. Wykorzystanie metody UMEWAP w ocenie funkcjonalności systemu informatycznego 30 VI.3. Podsumowanie zestawienie tabelaryczne 32 Spis tabel 37 Literatura 37 Politechnika Wrocławska, Wrocław 2007 3

1. Wstęp Ambitnie postawione zadanie zbudowania modelu słuŝącego do analizy funkcjonalności systemu MFG/PRO okazało się trudniejsze niŝ początkowo zakładaliśmy. Nasze prace rozpoczęliśmy od zdefiniowania mierników zawartych w normie ISO 9126. Na ich podstawie przygotowaliśmy zestaw kilkudziesięciu pytań, które pozwalają na dokonanie oceny, czy system jest funkcjonalny zgodnie z załoŝeniami normy. Ocena końcowa systemu jest wyliczana na podstawie metody naukowej UMEWAP. W rezultacie uzyskaliśmy opracowanie mogące słuŝyć jako przewodnik dla audytora systemu informatycznego, które pozwoli zrozumieć zawarte w normie wytyczne oraz zastosować je w praktyce. Dla poszczególnych miar funkcjonalności, które zostały przez nas zdefiniowane w tym raporcie opracowaliśmy metody ich szczegółowego mierzenia. Ustrukturalizowane, aczkolwiek często zbyt lapidarne, wytyczne normy ISO 9126 zastąpiliśmy obszernym komentarzem, dodając własne uwagi i propozycje konkretnych sposobów mierzenia funkcjonalności systemów informatycznych. Niniejsze opracowanie zawiera wiele dodatkowych elementów przydatnych w zrozumieniu tematu np.: teoretyczne aspekty badania danej subcharakterystyki, praktyczne znaczenie danej subcharakterystyki w zapewnianiu jakości oprogramowania, przykłady testów moŝliwych do zastosowania. Przygotowane przez nas opracowanie jest doskonałą podstawą do kontynuowania dalszych działań, czyli właściwego badania funkcjonalności systemu lub jego modułów. 1.1. Ewolucja podejścia Wyjściowym celem naszej pracy semestralnej była analiza kryteriów oceny funkcjonalności na podstawie wybranego systemu informatycznego. Swoje badania oparliśmy na definicjach oraz kryteriach funkcjonalności zawartych w normie ISO 9126. W trakcie prac nad interpretacją normy oraz jej zastosowaniem powstawały liczne wątpliwości, które dotyczyły: celu napisania normy, docelowego uŝytkownika normy (czy jest nim osoba tworząca czy teŝ sprawdzająca oprogramowanie np. audytor), zastosowania zdefiniowanych w normie mierników. Nawiązaliśmy kontakt z osobami zajmującymi się inŝynierią oprogramowania jednak uzyskanie materiałów pochodzących z konferencji poruszających problem jakości oprogramowania okazało się niemoŝliwe. Podjęliśmy zatem próbę analizy normy z punktu widzenia audytora, który na jej podstawie dokonuje przeglądu i oceny systemu. Norma nie mówi nic na temat samej procedury sprawdzania ani wagi poszczególnych ocen cząstkowych dla wystawienia oceny zagregowanej. Nie wiadomo, w jakim stopniu (lub w ilu procentach) naleŝy spełnić wymagania jakościowe, aby oprogramowanie uznać za spełniające wymagania normy. Wątpliwości budzi takŝe to czy twórcy, dostawcy oprogramowania są podmiotem czy przedmiotem oceny, czy teŝ jest nim wytwarzany przez nich produkt. Poszukiwanie odpowiedzi na postawione pytania rozpoczęliśmy od zapoznania się z treścią samej normy, a następnie dostępnych opracowań pochodzących z prasy branŝowej w Polsce i za granicą. PoniewaŜ norma ISO/IEC 9126 jest stosunkowo nowa, a problem jakości oprogramowania obecnie zyskuje na popularności, odnalezienie dostawcy, który posiada certyfikat okazało się niemoŝliwe. Podobnie wiedza teoretyczna, nie poparta praktyką czy wynikami badań nie wniosła nic do naszego opracowania. Początkowo, badanie funkcjonalności wybranego systemu informatycznego miało zostać oparte na systemie MFG/PRO wersja eb2. Wybór taki wynikał z faktu, Ŝe większość członków grupy współpracuje z firmą QAD producentem MFG/PRO. Jednak po analizie kryteriów oceny oraz konsultacji z prowadzącym doszliśmy do wniosku, Ŝe jeśli uda nam się zbadać zaledwie jakiś moduł tego oprogramowania pod kątem cech funkcjonalności oprogramowania to będzie znaczący postęp naszych prac. Cechą charakterystyczną zintegrowanych systemów zarządzania jest bowiem ich wysoka złoŝoność. Politechnika Wrocławska, Wrocław 2007 4

Nowym celem grupy była analiza kryteriów oceny funkcjonalności znajdujących się w normie, które zgodnie z tezą zostały uznane za prawidłowe, mające dostarczyć laikowi podstawowych informacji o miarach funkcjonalności: ich definicji, znaczeniu, przykładach zastosowania. Dogłębna analiza pozwoliła nam na zrozumienie znaczenia i zastosowania poszczególnych miar. Kolejnym naszym celem będzie określenie sposobu oceny oaz nadanie wag z określonego zakresu np. 1-10, a następnie opracowanie koncepcji przyznawania tych wag. W trakcie rozwaŝania moŝliwości testowania wybranego wcześniej oprogramowania doszliśmy do wniosku, iŝ zastosowanie wskazanych w normie mierników pomiaru systemu wymaga w większości specjalistycznej wiedzy z zakresu programowania. Nasz wiedza pozwoliłaby nam jedynie na ocenę funkcjonalności rozumianej jako spełnienie funkcji, dla których dany system został napisany i co zapisano w dokumentacji pod postacią Specyfikacji. Wtedy właśnie postanowiliśmy, Ŝe celem naszego zespołu w semestrze zimowym roku akademickiego 2006/2007 będzie szczegółowa analiza samej normy ISO 9126. KaŜdy z członków zespołu otrzymał zadanie opracowania jednej z miar funkcjonalności w zakresie: formalnej i nieformalnej definicji, znaczenia miary, przykładowych zastosowań. W końcowym etapie skupiliśmy się na przygotowaniu pytania (pytań) do kaŝdego z mierników, które jednoznacznie umoŝliwia ocenę funkcjonalności w danym obszarze. W celu lepszego zrozumienia pytania, kaŝde z nich zostało opatrzone komentarzem. Pytania te skupiają się na rzeczywistych zastosowaniach, a odpowiedź na nie ma postać tak (dana funkcjonalność jest spełniona) lub nie (dana funkcjonalność nie jest spełniona). Do zbudowania końcowego modelu oceny mierników posłuŝyliśmy się metodą UMEWAP. 1.2. Etapy tworzenia oprogramowania Zanim zajęliśmy się analizą normy zapoznaliśmy się z procedurą oraz etapami tworzenia oprogramowania. Zajmująca się tą tematyką inŝynieria oprogramowania zakłada, iŝ tworzenie produktu informatycznego przebiega w 3 fazach: analizy, projektu oraz implementacji. W fazie analizy następuje studium osiągalności, a zatem badanie wymagań przyszłych uŝytkowników oraz konstrukcja modeli biznesowych. W fazie projektu opracowywany jest szczegółowy plan implementacji systemu, będący uszczegółowieniem wyników analizy. Sama implementacja oznacza wytwarzanie oprogramowania w oparciu o szczegółowy projekt stworzony w fazie projektowania. Aby zapewnić odpowiednią jakość oprogramowania wykonuje się testy. Testowanie na kaŝdym poziomie wytwarzania oprogramowania, pozwala zweryfikować zgodność systemu z wymaganiami zdefiniowanymi w fazie analizy. Testy statyczne wykonywane głównie na dokumentacji analitycznej i projektowej oraz dokumentacji uŝytkownika mają za zadanie ocenić zgodność systemu z przepisami, wymogami dziedzinowymi (np. kadrowymi) itd. Ostatecznym procesem tej fazy jest wdroŝenie systemu. Przebieg procesu tworzenia oprogramowania pozwolił nam zrozumieć, na jakim etapie analiza jakościowa powinna być najbardziej intensywna. Tą fazą jest faza analizy. Oprócz zbadania wymagań, jakie uŝytkownicy stawiają przed oprogramowaniem naleŝy: sprawdzić czy te wymagania są realne i moŝliwe do spełnienia, zapisać je za pomocą odpowiedniej notacji, rozrysować schematy i przeanalizować dokładnie sposób ich implementacji (ocena moŝliwości spełnienia wymagań z punktu widzenia programisty), wstępnie sformułować daną funkcjonalność do specyfikacji. Politechnika Wrocławska, Wrocław 2007 5

1.3. Audyt funkcjonalności systemu Audyt to ocena organizacji, systemów, procesów czy produktów. 1.3.1. Cel Celem audytu funkcjonalności systemu moŝe być zapewnienie czytnikowi najwyŝszego poziomu satysfakcji. Dokładna okresowa kontrola i analiza systemu informatycznego umoŝliwia przede wszystkim szybsze i skuteczniejsze reagowanie w sytuacjach awaryjnych, w wielu przypadkach nawet im zapobiega. Podczas przeprowadzania audytu funkcjonalności aplikacji mogą być przeanalizowane poszczególne cechy funkcjonalności podane w normie ISO 9126. Najistotniejsza wydaje się kontrola wewnętrzna. 1.3.2. Etapy przeprowadzania audytu funkcjonalności systemu informatycznego 1. Zbieranie danych Na tym etapie wykonywane jest porównanie funkcjonalności systemu z jego załoŝeniami w specyfikacji, kodem źródłowym i opiniami uŝytkownika. System skanowany jest przez eksperta.3 2. Analiza danych Zebrane informacje dotyczące zainstalowanego oprogramowania oraz informacje dotyczące posiadanych funkcjonalności wprowadzane są arkusza, gdzie są one sumowane, zestawiane i porównywane. 3. Tworzenie raportów Na podstawie informacji uzyskanych w poprzednich etapach tworzone są szczegółowe raporty i zestawienia obrazujące stan oprogramowania: jego funkcjonalności, zestawienia ilościowe, posiadane braki/ nadwyŝki w oprogramowaniu, niechciane pliki. 4. Działania naprawcze W przypadku wykrycia braków bądź błędów w aplikacji, ustalamy najkorzystniejszą formę ich usunięcia. Politechnika Wrocławska, Wrocław 2007 6

2. Funkcjonalność 2.1. Definicje funkcjonalności Zagadnienie funkcjonalności, które stanowi główny przedmiot zainteresowania prowadzonych przez nas badań zostało zdefiniowane w wielu źródłach róŝnoraki sposób. 1. Funkcjonalność (Functionality) wg ISO/IEC 9126 to zdolność oprogramowania do dostarczenia funkcji zaspokajających wyznaczone i zakładane potrzeby, podczas uŝywania go w określonych warunkach. Uwaga: Ta cecha odpowiada za wyjaśnienie, jakie warunki zostały spełnione przez oprogramowanie dla spełnienia wymagań, podczas gdy inne cechy są głównie związane z tym, kiedy oraz jak oprogramowanie spełnia dane wymagania. 2. Funkcjonalność wg definicji zamieszczonej w serwisie whatis.com to suma wszystkich tych aspektów działania oprogramowania, które wykonują czynności dla uŝytkownika. Identyfikuje cechy oprogramowania. 3. Z kolei Funkcjonalność wg definicji zamieszczonej w serwisie wordreference.com to zdolność do prawidłowego wypełniania postawionych zadań. Według normy ISO 9126 do podstawowych wyznaczników(miar) funkcjonalności zaliczamy: Suitability Odpowiedniość Accuracy Dokładność Interoperability Współdziałanie Security Bezpieczeństwo Functionality compliance - Zgodność W dalszej części opracowania zaprezentujemy szczegółową analizę poszczególnych wyznaczników funkcjonalności wykonaną na podstawie studium literaturowego oraz naszej wiedzy z zakresu inŝynierii oprogramowania. Politechnika Wrocławska, Wrocław 2007 7

I. Funkcjonalność wg ISO 9126. ODPOWIEDNIOŚĆ Słownik WordNet 2.0 określa odpowiedniość (ang. suitability) jako cechę posiadania własności, które są właściwe dla określonego celu. Odpowiedniość w ramach oprogramowania komputerowego, będziemy więc rozumieć jako atrybut oprogramowania, który opisuje obecność i dopasowanie zbioru funkcji wykonujących określone zadania. Jako atrybut oprogramowania moŝe występować funkcja lub ich zbiór (Np. Zaimplementowane w kodzie źródłowym), jak równieŝ funkcja jako moŝliwość wykonania odpowiednich czynności (np. wydruk raportu, wyświetlenie określonej informacji, przesłanie danych do zewnętrznego źródła). Określone zadania, o których mówi definicja, mogą zostać podane jako wymaganie określone przez specyfikację lub uŝytkownika oprogramowania. Badanie odpowiedniości polega na sprawdzeniu czy oprogramowanie spełnia zadane wymagania oraz w jakim stopniu. Do pomiaru odpowiedniości słuŝą określone ku temu mierniki. I.1. Mierniki zewnętrzne. I.1.1 Funkcjonalna adekwatność. Miernik ocenia czy zaimplementowane funkcje są adekwatne do postawionych wymagań. Ocena wynikająca z tego miernika wskazuje więc czy działanie systemu (w szczególności wynik działania określonych jego funkcjonalności) spełnia załoŝenia ze specyfikacji. Pytanie: Czy uŝytkownik ocenia, Ŝe rezultat działania zaimplementowanych modułów otrzymany w systemie jest zgodny z opisanym w specyfikacji? Wskazówka: NaleŜy wybrać funkcjonalność jaka była zakładana w specyfikacji i sprawdzić czy to co zostało zaimplementowane (samo działanie oraz jego wynik) odpowiada temu co było załoŝone. Uznaliśmy miernik za kluczowy, poniewaŝ walidacja systemu (sprawdzenie czy spełnia załoŝone wymagania) jest jednym z najwaŝniejszych kryteriów wskazujących czy projekt zakończył się sukcesem. Pytanie: Czy uŝytkownik nie zgłasza uwag do formatu danych wprowadzanych do systemu? Czy kluczowe? Nie. Wskazówka: Przykładowo moŝe nie odpowiadać nam format wpisywania daty rozpoczęcia zlecenia. Nie jest kluczowe, bo łatwo to zmienić, ale waŝne Ŝeby uŝytkownik końcowy miał to co opisał w specyfikacji. Kluczowym byłby fakt, Ŝe daty nie moŝna wprowadzić, mimo zapisu w specyfikacji. Pytanie: Czy uŝytkownik nie zgłasza uwag do sposobu wprowadzania danych do systemu? Czy kluczowe? Nie. Wskazówka: Przykładowo zaimplementowaliśmy pole wyboru z ograniczoną liczbą elementów na liście (przykładowo status zamówienia). UŜytkownik chciałby móc dodawać nowe. Lub pewne dane ustawiliśmy jako obligatoryjne do wprowadzenia, uŝytkownik chce mieć moŝliwość nie wprowadzania tych danych. I.1.2. Kompletność implementacji funkcjonalnej. Miernik ocenia czy wymagane funkcje zostały zaimplementowane. Kompletność moŝe być miernikiem pomocnym w ocenie ile wymagań określonych w specyfikacji zostało podczas projektu pominiętych. Zespół programistów powinien umieć uargumentować powody niekompletności systemu, w przeciwnym wypadku moŝe to odbić się na kosztach projektu (dodatkowe dni poświęcone na uzupełnianie niekompletnych modułów lub niezapłacenie przez klienta umówionej kwoty). Ten miernik uznaliśmy za kluczowy. Pytanie: Czy uŝytkownik ocenia, Ŝe wszystkie wymagane funkcjonalności (określone moduły) są dostępne? Politechnika Wrocławska, Wrocław 2007 8

Pytanie: Czy uŝytkownik ocenia, Ŝe wszystkie specyficzne wymagania (nie ujęte w specyfikacji) zostały zaimplementowane? Wskazówka: Wykonuję test funkcjonalny programu polegający na czytaniu specyfikacji i próbie uruchomienia opcji w menu (waŝne czy są dostępne a nie jak działają, to ocenia miernik znajdujący się powyŝej). Sprawdzam równieŝ implementację wymagań dodatkowych. I.2. Mierniki wewnętrzne. Mierniki wewnętrzne odpowiedniości mają znaczenie wówczas, gdy były wyspecyfikowane wymagania (odnośnie określonego sposobu działania i/lub wyniku) do funkcji / modułów na poziomie kodu źródłowego. Takie wymagania mogą być wynikiem kultury organizacyjnej przedsiębiorstwa, które implementuje system. Mogą istnieć wewnętrzne ograniczenia dotyczące sposobu pisania kodu, ma to uzasadnienie, gdy nad jednym projektem pracuje wielu programistów. I.2.1. Funkcjonalna adekwatność Pytanie: Czy kierownik projektu nie ma uwag do działania zaimplementowanych funkcji (zbyt duŝe uŝycie pamięci, wolne działanie)? Czy kluczowe? Nie. Pytanie: Czy kierownik projektu ocenia, Ŝe zaimplementowane funkcje / moduły będą spełniać zadania postawione w wymaganiach? Wskazówka: Podstawowym warunkiem wykonania testu jest dostęp do kodu źródłowego. NaleŜy wybrać funkcje lub moduły jakie miały być zaimplementowane i sprawdzić ich działanie. I.2.2. Kompletność implementacji funkcjonalnej. Ten miernik jest pomocny przy ocenie kompletności projektu przez kierownika. JeŜeli kierownik projektu wykorzysta go jako wskazówkę do oceny kompletności implementacji systemu, moŝe w ten sposób upewnić się, Ŝe ocena za pomocą mierników zewnętrznych wypadnie pomyślnie. Pytanie: Czy kierownik projektu potwierdza zaimplementowanie funkcji / modułów ujętych w wymaganiach / specyfikacji? Pytanie: Czy kierownik projektu ocenia, Ŝe zaimplementowane funkcje / moduły pozwolą na spełnienie przez system specyficznych wymagań uŝytkownika (nie ujętych w specyfikacji)? Wskazówka: Podstawowym warunkiem wykonania testu jest dostęp do kodu źródłowego. Weryfikujemy kompletność implementacji i wynikającą z niej zgodność ze specyfikacją. Sprawdzam równieŝ implementację wymagań dodatkowych. Zamiast kierownika projektu osobą oceniającą moŝe być programista. Politechnika Wrocławska, Wrocław 2007 9

Tabela 1 Zewnętrzne i wewnętrzne wymiary odpowiedniości. Opracowanie własne. M Lp. Miernik Pytanie Czy kluczowe? Ocena (0/1) Waga punktowa Wynik [%] Udział procentowy MIERNIKI ZEWNĘTRZNE 1. Funkcjonalna adekwatność Czy uŝytkownik ocenia, Ŝe rezultat działania zaimplementowanych modułów otrzymany w systemie jest zgodny z opisanym w specyfikacji? Tak 70 16,28% 2. Funkcjonalna adekwatność Czy uŝytkownik nie zgłasza uwag do formatu danych wprowadzanych do systemu? Nie 35 8,14% ODPOWIEDNIOŚĆ = 430 pkt 3. Funkcjonalna adekwatność 4. 5. Kompletność implementacji funkcjonalnej Kompletność implementacji funkcjonalnej 6. Funkcjonalna adekwatność 7. Funkcjonalna adekwatność Kompletność 8. implementacji funkcjonalnej Kompletność 9. implementacji funkcjonalnej Czy uŝytkownik nie zgłasza uwag do sposobu wprowadzania danych do systemu? Czy uŝytkownik ocenia, Ŝe wszystkie wymagane funkcjonalności (określone moduły) są dostępne? Czy uŝytkownik ocenia, Ŝe wszystkie specyficzne wymagania (nie ujęte w specyfikacji) zostały zaimplementowane? MIERNIKI WEWNĘTRZNE Czy kierownik projektu nie ma uwag do działania zaimplementowanych funkcji (zbyt duŝe uŝycie pamięci, wolne działanie)? Czy kierownik projektu ocenia, Ŝe zaimplementowane funkcje / moduły będą spełniać zadania postawione w wymaganiach? Czy kierownik projektu potwierdza zaimplementowanie funkcji / modułów ujętych w wymaganiach / specyfikacji? Czy kierownik projektu ocenia, Ŝe zaimplementowane moduły pozwolą na spełnienie przez system specyficznych wymagań uŝytkownika (nie ujętych w specyfikacji)? Nie 15 3,49% Tak 55 12,79% Tak 40 9,30% Nie 30 6,98% Tak 75 17,44% Tak 70 16,28% Tak 40 9,30% Politechnika Wrocławska, Wrocław 2007 10

II. Funkcjonalność wg ISO 9126. DOKŁADNOŚĆ Dokładność oprogramowania (ang. accuracy) według normy ISO jest to zdolność oprogramowania do zapewnienia zgodnych I ustalonych rezultatów i efektów z wymaganą precyzją. Aby zrozumieć definicję naleŝy rozgraniczyć pojawiające się w niej pojęcia: dokładności i precyzji. Dokładność pomiaru jest miarą tego jak wyniki doświadczalne są bliskie wartości prawdziwej lub przyjętej za prawdziwą. Precyzja pomiaru natomiast jest miarą rzetelności przeprowadzenia doświadczenia, lub mówi nam jak powtarzalny jest ten eksperyment. Jeśli kilkukrotnie powtarzane zadanie daje ten sam rezultat moŝemy ocenić system jako precyzyjny. Natomiast to czy ten rezultat jest zgodny z oczekiwanym czy nie świadczy o jego dokładności. W naszym przypadku system powinien dawać zarówno rezultaty dokładne jak i precyzyjne. Tak rozumiana dokładność stanowi bardzo waŝną cechę systemów, twórcom systemu zaleŝy na spójności oraz integralności danych, która przekłada się na dokładność otrzymywanych wyników oraz poprawność ich przetwarzania (precyzję). II.1. Mierniki zewnętrzne Zewnętrzna analiza dokładności powinna pozwalać na zmierzenie jak często uŝytkownicy systemu natrafiają na nieoczekiwane zachowania systemu tj.: nieprawidłowe lub nieprecyzyjne rezultaty spowodowane nieodpowiednimi danymi, przykładowo dane zawierające zbyt wiele cyfr uniemoŝliwiające dokonanie odpowiedniej kalkulacji, brak konsekwencji faktycznie wykonywanych operacji z opisem ich przebiegu w specyfikacji, róŝnice pomiędzy faktycznym przebiegiem procedur a ich opisem w specyfikacji. Badanie odbywa się poprzez porównanie informacji wprowadzanych na wejściu i otrzymywanych na wyjściu rezultatów. Sprowadza się to do zliczenia napotkanych przez uŝytkownika zdarzeń niezgodnych z oczekiwanymi, gdzie oprócz ilości istotnym moŝe okazać się czas trwania kaŝdego z niedopuszczalnych zdarzeń. Dokonanie oceny przebiega w oparciu o wymagania znajdujące się w specyfikacji i najczęściej polega na uzupełnianiu pól danymi i generowaniu raportów. 2.1.1. Oczekiwana dokładność Dokonujący przeglądu audytor oraz korzystający z systemu uŝytkownicy muszą odpowiedzieć na pytanie: czy róŝnice pomiędzy oczekiwanymi i uzyskiwanymi rezultatami mieszczą się w granicy rozsądku. NaleŜy sprawdzić czy uŝytkownik napotkał na trudności z komunikacją z systemem. Punktem wyjścia do oceny jest specyfikacja, która w jasny sposób powinna wskazywać na postać uzyskiwanych raportów. W przypadku wykonania niedozwolonych operacji prawidłowo napisany program powinien wyświetlić komunikat ostrzegawczy. Gotowy program powinien nie tylko w pełni odpowiadać wymaganiom zdefiniowanym w specyfikacji, ale być odporny na nieoczekiwane reakcje uŝytkownika ( idiotoodpornośc ). Pytanie: Czy testy funkcjonalne wykonywane przez twórców systemu wskazują na rozbieŝności pomiędzy specyfikacją a rzeczywista reakcją systemu? Czy kluczowe? Nie. Pytanie: Czy uŝytkownik zgłasza, iŝ nieoczekiwane reakcje ze strony systemu utrudniają jego pracę? Politechnika Wrocławska, Wrocław 2007 11

Pytanie: Czy próba wprowadzenia przez uŝytkownika systemu błędnego formatu danych w pola kończy się powodzeniem? Wskazówka: NaleŜy wykonać test polegający na próbie wpisywania przypadkowych danych w pola i sprawdzić czy system przyjmie je czy teŝ poinformuje o próbie dokonania niedozwolonej operacji. 2.1.2. Dokładność obliczeniowa Ocena dokładności sprowadza się do rejestrowania zdarzeń nieoczekiwanych, innych od zdarzeń zdefiniowanych w dokumentacji systemu. Aby dokonać pełnej oceny systemu naleŝy takŝe sprawdzić jak często takie niezgodności napotyka uŝytkownik końcowy. Pytanie: Czy uŝytkownik końcowy skarŝy się na częste uzyskiwanie rezultatów niezgodnych z dokumentacją? Pytanie: Czy wystąpienie nieoczekiwanego rezultatu jest rozpoznawane i rejestrowane przez system? (komunikaty o błędzie) Wskazówka: Na typ etapie sprawdzana jest reakcja systemu na błędne dane, które wpisali uŝytkownicy. W przypadku prawidłowych mechanizmów błędne dane, nie dające się przeliczyć powinny spowodować reakcję systemu w postaci komunikatów (przejrzystość tych komunikatów, wskazanie miejsca, w którym wystąpił błąd powinno ułatwić uŝytkownikowi powrót we właściwe miejsce i usunięcie niezgodności). 2.1.3. Precyzja Celem uŝycia miernika jest sprawdzenie precyzji systemu. Precyzja mówi o jakości systemu i zaimplementowanych w nim mechanizmów słuŝących przeliczaniu danych. Aby ocenić precyzję naleŝy przeprowadzić test wielokrotnie i porównać uzyskiwane wyniki. Jeśli wyniki są takie same system cechuje wysoka precyzyjność. Wówczas wystąpienie błędów nie jest przyczyną źle skonstruowanego aparatu obliczeniowego. Pytanie: Czy wielokrotnie przeprowadzony test funkcjonalny daje taki sam rezultat? Wskazówka: W sytuacji systemów dokonujących obliczeń księgowych, fakturowania jakiekolwiek rozbieŝności są niedopuszczalne. Dlatego uznaliśmy ten miernik za kluczowy. W przypadku systemu, który dokonuje pomiaru czasu, temperatury czy innych właściwości i jest obsługiwany przez operatora nie moŝna uznać precyzji za miernik kluczowy. Nawet gdy urządzenie, którym dokonujemy pomiaru jest precyzyjne precyzja pomiaru zaleŝy takŝe od uŝytkownika. Dlatego tez zalecane jest, aby odpowiednio zdefiniować powyŝszy miernik przed dokonaniem oceny systemu. Politechnika Wrocławska, Wrocław 2007 12

II.2. Mierniki wewnętrzne ISO 9126 definiuje dwa mierniki wewnętrzne w odniesieniu do obszaru dokładności (internal accuracy metrics). Są one związane z zapewnieniem w oprogramowaniu dokładności obliczeniowej oraz precyzji obliczeń. Za pomocą mierników wewnętrznych sprawdzimy, czy wszystkie funkcje, mechanizmy i standardy związane z zapewnieniem dokładności zapisane w specyfikacji oprogramowania zostały zaimplementowane w gotowym produkcie. 2.2.1. Dokładność obliczeniowa Celem tego miernika jest sprawdzenie, czy wszystkie mechanizmy i standardy związane z zapewnieniem w programie dokładności obliczeniowej, które zapisano w specyfikacji (wymaganiach oprogramowania) zostały zaimplementowane w gotowym produkcie. Pytanie: Czy we wszystkich funkcjach programu, w których konieczne jest zapewnienie dokładności obliczeniowej zostały zaimplementowane odpowiednie mechanizmy i standardy zgodnie z wymaganiami zapisanymi w specyfikacji? Wskazówka: NaleŜy porównać stan obecny (gotowy program) z wymaganiami projektowymi, specyfikacją programu, jego kodem źródłowym oraz informacjami pochodzącymi z przeglądu jego funkcjonalności. Informacje te naleŝy zasięgnąć u osoby definiującej wymagania programu oraz osoby rozwijającej program (programisty). MoŜna przeprowadzić szereg testów, które jednoznacznie wykaŝą poziom dokładności obliczeniowej, który moŝna uzyskać podczas pracy z programem. 3.2.2 Precyzja Celem tego miernika jest sprawdzenie, czy gotowy program dokonuje obliczeń zapewniając poziom precyzji, który zapisano w specyfikacji (wymaganiach oprogramowania). Gotowy program powinien w pełni odpowiadać wymaganiom zdefiniowanym w specyfikacji. Pytanie: Czy gotowy program dokonuje obliczeń z wymaganym poziomem precyzji, który zapisano w specyfikacji? Wskazówka: NaleŜy porównać stan obecny (gotowy program) z wymaganiami projektowymi, specyfikacją programu, jego kodem źródłowym oraz informacjami pochodzącymi z przeglądu jego funkcjonalności. Informacje te naleŝy zasięgnąć u osoby definiującej wymagania programu oraz osoby rozwijającej program (programisty). MoŜna przeprowadzić szereg testów, które jednoznacznie wykaŝą poziom precyzji obliczeniowej, który moŝna uzyskać podczas pracy z programem. Politechnika Wrocławska, Wrocław 2007 13

Tabela 2 Zewnętrzne i wewnętrzne wymiary dokładności. Opracowanie własne. M Lp. Miernik Pytanie Czy kluczowe? Ocena (0/1) Waga punktowa Wynik Udział procentowy [%] MIERNIKI ZEWNĘTRZNE 1. Oczekiwana dokładność Czy testy funkcjonalne wykonywane przez twórców systemu wskazują na rozbieŝności pomiędzy specyfikacją a rzeczywistą reakcją systemu? Nie 40 9,3% 2. Oczekiwana dokładność Czy uŝytkownik zgłasza, iŝ nieoczekiwane reakcje ze strony systemu utrudniają jego pracę? Tak 70 16,3% D O K Ł A D N O Ś Ć = 430 pkt 3. 4. 5. Oczekiwana dokładność Dokładność obliczeniowa Dokładność obliczeniowa 6. Precyzja Czy próba wprowadzenia przez uŝytkownika systemu błędnego formatu danych w pola kończy się powodzeniem? Czy uŝytkownik końcowy skarŝy się na częste uzyskiwanie rezultatów niezgodnych z dokumentacją? Czy wystąpienie nieoczekiwanego rezultatu jest rozpoznawane i rejestrowane przez system? (komunikaty o błędzie) Czy wielokrotnie przeprowadzony test funkcjonalny daje taki sam rezultat? MIERNIKI WEWNĘTRZNE Tak 70 16,3% Tak 60 13,9% Tak 40 9,3% Tak 50 11,6% 7. Dokładność obliczeniowa Czy we wszystkich funkcjach programu, w których konieczne jest zapewnienie dokładności obliczeniowej zostały zaimplementowane odpowiednie mechanizmy i standardy zgodnie z wymaganiami zapisanymi w specyfikacji? Tak 50 11,6% 8. Precyzja Czy gotowy program dokonuje obliczeń z wymaganym poziomem precyzji, który zapisano w specyfikacji? Tak 50 11,6% Politechnika Wrocławska, Wrocław 2007 14

III. Funkcjonalność wg ISO 9126. WSPÓŁDZIAŁANIE III.1. Mierniki zewnętrzne 3.1.1. Kompatybilność Pytanie: Czy w badanych systemach istnieją funkcjonalności, które działają wspólnie z innymi systemami? Wskazówka: Warunkiem wykonania testu jest dostęp do kilku systemów jednocześnie. NaleŜy sprawdzić funkcje, których integracja pozwala na wspólne działanie. Test polega na testowaniu kaŝdego systemu. 3.1.2. Środowisko programowe Pytanie: Czy badane systemy są napisane w tym samym języku? Czy kluczowe? Nie. Pytanie: Czy badane systemy pracują na takim samym systemie operacyjnym? Czy kluczowe? Nie. skazówka: Wykonanie tego testu polega na ominięciu mechanizmu aplikacji, a dotarciu tylko do systemu operacyjnego i kodu źródłowego systemu. 3.1.3. Współdziałanie techniczne Pytanie: Czy systemy posiadają moŝliwość komunikacji ze sobą (np. poprzez wspólny interfejs uŝytkownika)? Czy kluczowe? Nie. Pytanie: Czy systemy posiadają wspólną bazę danych? Czy kluczowe? Nie. Pytanie: Czy pomiędzy systemami istnieje moŝliwość importu/eksportu danych z/do drugiego systemy? Czy kluczowe? Nie. Wskazówki: Istotą tego poziomu jest udostępnienie programiście przez istniejącą aplikację moŝliwości uruchomienia swoich funkcji wewnętrznych. Podczas przyłączania kolejnych aplikacji tworzy się skomplikowana struktura powiązań aplikacja-aplikacja. Jest ona testowana i w ten sposób osoba testująca ocenia stopień ich współdziałania. Wskazówki: Badanie współdziałania systemu metodami zewnętrznymi powinno polegać na porównaniu go z innym systemem/systemami. III.2. Mierniki wewnętrzne 3.2.1. Formaty danych Pytanie: Czy załoŝone w specyfikacji formaty danych zostały zaimplementowane w badanej aplikacji? Politechnika Wrocławska, Wrocław 2007 15

3.2.2. Preferencje uŝytkownika Pytanie: Czy wszystkie specyficzne wymagania uŝytkownika (nie ujęte w specyfikacji) zostały zaimplementowane? Czy kluczowe? Nie. Wskazówka: Przy ocenie tego miernika powinni uczestniczyć zarówno programista, jak i uŝytkownik/uŝytkownicy aplikacji. Pozwala to z jednej strony porównać załoŝenia specyfikacji z kodem źródłowym, z drugiej zaś pozwala na sprawdzić potrzeby uŝytkownika z funkcjonalnościami aplikacji. 3.2.3. Formaty protokołów Pytanie: Czy w systemie liczba zaimplementowanych formatów protokołów jest zgodna ze specyfikacją? Czy kluczowe? Nie. Wskazówki: Test ten powinna przeprowadzać osoba rozwijająca program (programista) lub osoba definiująca wymagania systemu. Osoba ta musi posiadać dostęp do kodu źródłowego i specyfikacji badanej aplikacji. Politechnika Wrocławska, Wrocław 2007 16

Tabela 3 Zewnętrzne i wewnętrzne wymiary współdziałania. Opracowanie własne. Lp Miernik Pytanie Czy kluczowe? Waga punktowa Udział procentow [%] MIERNIKI ZEWNĘTRZNE 1. Kompatybilność Czy w badanych systemach istnieją funkcjonalności, które działają wspólnie z innymi systemami? Tak 40 9,52% 2. Środowisko programowe Czy badane systemy są napisane w tym samym języku? Nie 15 3,57% 3. Środowisko programowe Czy badane systemy pracują na takim samym systemie operacyjnym? Nie 15 3,57% Współdziałanie = 420 4. 5. 6. Współdziałanie techniczne Współdziałanie techniczne Współdziałanie techniczne Czy systemy posiadają moŝliwość komunikacji ze sobą (np. poprzez wspólny interfejs uŝytkownika)? Tak 60 14,29% Czy systemy posiadają wspólną bazę danych? Tak 45 10,71% Czy pomiędzy systemami istnieje moŝliwość importu/eksportu danych z/do drugiego systemy? Tak 30 7,14% MIERNIKI WEWNĘTRZNE 7. Formaty danych Czy załoŝone w specyfikacji formaty danych zostały zaimplementowane w badanej aplikacji? Tak 65 15,48% 8. Preferencje uŝytkownika Czy wszystkie specyficzne wymagania uŝytkownika (nie ujęte w specyfikacji) zostały zaimplementowane? Tak 75 17,86% 9. Formaty protokołów Czy w systemie liczba zaimplementowanych formatów protokołów jest zgodna ze specyfikacją? Tak 75 17,86% Politechnika Wrocławska, Wrocław 2007 17

V. Funkcjonalność wg ISO 9126. BEZPIECZEŃSTWO IV.1. Mierniki zewnętrzne ISO 9126 definiuje trzy podstawowe mierniki zewnętrzne. SłuŜą one do mierzenia charakterystyk związanych z występowaniem luk w oprogramowaniu, którymi są: niemoŝność zapobieŝenia wyciekowi informacji i danych, niemoŝność zapobieŝenia utracie waŝnych danych, niemoŝność obrony przed nieuprawnionym dostępem do danych lub wykonaniem nieuprawnionych operacji. Mierniki te odnoszą się do istniejącego systemu (oprogramowania), na którym przeprowadza się testy. Takimi testami mogą być: testy polegające na celowym przeprowadzaniu prób naruszenia bezpieczeństwa systemu, testy polegające na monitorowaniu działającego systemu. Na podstawie analizy wyników testu moŝna ocenić, czy system (oprogramowanie) jest bezpieczne, czy teŝ nie. Podsumowując mierniki zewnętrzne związane są z oceną oprogramowania na podstawie funkcjonowania systemu i znajdują zastosowanie w trakcie testów i eksploatacji. 4.1.1. Audyt dostępu Za pomocą tego miernika naleŝy ocenić liczbę zarejestrowanych w dzienniku zdarzeń (logu) prób dostępu do systemu w stosunku do rzeczywistej liczby zdarzeń związanych z dostępem uŝytkowników do danych systemowych. Inaczej mówiąc: naleŝy sprawdzić, czy wszystkie próby dostępu przez uŝytkowników do danych są rejestrowane w dzienniku zdarzeń. Prawidłowo napisany program powinien rejestrować w dzienniku zdarzeń wszystkie próby dostępu do danych. Pytanie: Czy wszystkie próby dostępu do danych są rejestrowane w dzienniku zdarzeń? Wskazówka: NaleŜy wykonać test, który będzie polegał na próbie uzyskania dostępu do danych, na wszystkie moŝliwe w programie sposoby. Następnie naleŝy sprawdzić, czy wszystkie te próby zostały zarejestrowane w dzienniku zdarzeń. 4.1.2. Kontrola dostępu Tutaj norma odnosi się do porównywania liczby wykrytych nielegalnych operacji dostępu do systemu (róŝnych typów) z liczbą typów nielegalnych operacji, które podano w specyfikacji tzn. znanych, wcześniej zdefiniowanych. Prawidłowo napisany program powinien rejestrować wszystkie tego typu naruszenia. Pytanie: Czy wszystkie (znane, wcześniej zdefiniowane) próby nielegalnego dostępu do danych są rejestrowane w dzienniku zdarzeń? Wskazówka: NaleŜy wykonać test, który będzie polegał na próbie uzyskania nielegalnego dostępu do danych. Test taki naleŝy przygotować bazując na specyfikacji, która powinna jednoznacznie wskazywać jakie typy (sposoby) nieuprawnionego dostępu mogą mieć miejsce w pracy z systemem. Następnie naleŝy sprawdzić, czy wszystkie te próby zostały zarejestrowane w dzienniku zdarzeń. Politechnika Wrocławska, Wrocław 2007 18

4.1.3. Zapobieganie utracie danych Za pomocą tego miernika naleŝy zbadać jak często zachodzą zdarzenia związane z utratą danych. Dodatkowymi kryteriami, które naleŝy uwzględnić są zdarzenia, w przypadku których moŝliwe jest odzyskanie danych oraz takie, w których utrata danych wynikała z ich celowego zniszczenia. Zdarzeń związanych z utratą danych nie da się wykluczyć, choć oczywiście powinno być ich jak najmniej. W zaleŝności od stopnia bezpieczeństwa, który chcemy uzyskać, powinniśmy ograniczyć do minimum ryzyko trwałej utraty danych poprzez np. wykonywanie częstych (kaŝdego dnia) kopii zapasowych, czy replikacji danych na dwóch, trzech niezaleŝnych dyskach serwerach. Pytanie: Czy pracownik lub osoba zewnętrzna ma moŝliwość celowego zniszczenia danych lub nośników, na których te dane są przechowywane? Uwzględnić moŝliwość fizycznego zniszczenia oraz skasowania danych za pomocą dostępnych w programie funkcji. Pytanie: Czy oprogramowanie jest podatne na przypadkowe skasowanie lub zniszczenie danych? Czy uŝytkownik, korzystając z dostępnych funkcji moŝe nieświadomie i w sposób niezamierzony skasować lub zniszczyć dane? Pytanie: Czy w firmie zastosowano moŝliwie najlepsze urządzenia gwarantujące bezpieczeństwo przechowywania danych? Czy kluczowe? Nie. Pytanie: Czy wykonywany jest regularna (kaŝdego dnia lub częściej) kopia zapasowa (backup) danych? Pytanie: Czy oprogramowanie umoŝliwia łatwe i skuteczne wykonywanie i odtwarzanie danych z kopii zapasowych? Pytanie: Czy stosowane są mechanizmy replikacji danych na dwóch lub więcej niezaleŝnych dyskach twardych? Czy kluczowe? Nie. Pytanie: Czy testowane oprogramowanie umoŝliwia zastosowanie mechanizmów replikacji? Czy kluczowe? Nie. Wskazówka: NaleŜy przeprowadzić wywiad (badanie), które da odpowiedź na powyŝsze pytania. PoniewaŜ zagadnienia związane z zapobieganiem utracie danych mają złoŝony charakter, naleŝy posłuŝyć się wiedzą ekspercką. W celu uzyskania odpowiedzi ekspert wykorzystuje własną wiedzę i doświadczenie oraz przyjęte załoŝenia w zaleŝności od stopnia bezpieczeństwa, którego osiągnięcie jest konieczne. Ekspert moŝe takŝe posłuŝyć się dodatkowymi testami polegającymi na: zliczeniu wszystkich zdarzeń związanych z trwałą utratą waŝnych danych w stosunku do liczby zdarzeń, które związane były z ich celowym zniszczeniem, zliczeniu wszystkich zdarzeń związanych z utratą danych w stosunku do tych, w przypadku których udaje się je odzyskać. Testy te wymagają jednak dłuŝszego czasu i nie zawsze mogą zostać przeprowadzone. Politechnika Wrocławska, Wrocław 2007 19

IV.2. Mierniki wewnętrzne ISO 9126 definiuje pięć podstawowych mierników wewnętrznych. Mierniki te związane są z badaniem jakości oprogramowania pod kątem analizy wykonania programu. Za pomocą mierników wewnętrznych sprawdzimy, czy wszystkie funkcje realizowane przez program zapisane w jego specyfikacji (wymaganiach) zostały zaimplementowane w gotowym produkcie. Podsumowując - mierniki wewnętrzne umoŝliwiają bezpośrednią ocenę oprogramowania (jakości jego wytwarzania) i znajdują zastosowanie w trakcie projektowania i kodowania. 4.2.1. Audyt dostępu Celem tego miernika jest sprawdzenie, czy wszystkie sposoby dostępu do systemu (oprogramowania), które zapisano w specyfikacji (wymaganiach oprogramowania) zostały zaimplementowane w oprogramowaniu. Miernik ten sprawdza, czy w oprogramowaniu w pełni zaimplementowano funkcje związane z audytowaniem (rejestrowaniem) prób dostępu do systemu. Gotowy program powinien w pełni odpowiadać wymaganiom zdefiniowanym w specyfikacji. Pytanie: Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy związane z rejestrowaniem w dzienniku zdarzeń prób dostępu do danych zostały zaimplementowane w badanej wersji programie? Wskazówka: NaleŜy porównać stan obecny (gotowy program) ze specyfikacją. Informacje naleŝy zasięgnąć u projektanta i programisty danego oprogramowania. Test ten moŝe zostać przeprowadzony przez osobę rozwijająca program (programista) lub osobę definiującą wymagania systemu. 4.2.2. Kontrola dostępu Celem tego miernika jest sprawdzenie, czy wszystkie funkcje kontroli dostępu (np. logowania wejść, Ŝądania haseł o wymaganej długości itd.), które zapisano w specyfikacji (wymaganiach oprogramowania) zostały zaimplementowane w oprogramowaniu. Miernik ten sprawdza, czy w oprogramowaniu w pełni zaimplementowano funkcje związane z kontrolowaniem dostępu do danych. Gotowy program powinien w pełni odpowiadać wymaganiom zdefiniowanym w specyfikacji. Pytanie: Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy związane z rejestrowaniem w dzienniku zdarzeń nielegalnych prób dostępu do danych zostały zaimplementowane w programie? Wskazówka: NaleŜy porównać stan obecny (gotowy program) ze specyfikacją. Informacje naleŝy zasięgnąć u projektanta i programisty danego oprogramowania. Test ten moŝe zostać przeprowadzony przez osobę rozwijająca program (programista) lub osobę definiującą wymagania systemu. 4.2.3. Zapobieganie utracie danych Celem tego miernika jest sprawdzenie, czy wszystkie funkcje zapobiegające utracie danych (np. automatyczne tworzenie kopii zapasowych), które zapisano w specyfikacji (wymaganiach oprogramowania) zostały zaimplementowane w oprogramowaniu. Miernik ten sprawdza, czy w oprogramowaniu w pełni zaimplementowano funkcje zapobiegające utracie danych. Gotowy program powinien w pełni odpowiadać wymaganiom zdefiniowanym w specyfikacji. Politechnika Wrocławska, Wrocław 2007 20

Pytanie: Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy związane z zapobieganiem utracie danych zostały zaimplementowane w programie? Wskazówka: NaleŜy porównać stan obecny (gotowy program) ze specyfikacją. Informacje naleŝy zasięgnąć u projektanta i programisty danego oprogramowania. Test ten moŝe zostać przeprowadzony przez osobę rozwijająca program (programistę). 4.2.4. Szyfrowanie danych Celem tego miernika jest sprawdzenie, czy wszystkie funkcje związane z szyfrowaniem i deszyfrowanie danych, które zapisano w specyfikacji (wymaganiach oprogramowania) zostały zaimplementowane w gotowym oprogramowaniu. Miernik ten sprawdza, czy w oprogramowaniu w pełni zaimplementowano mechanizmy szyfrowania danych. Gotowy program powinien w pełni odpowiadać wymaganiom zdefiniowanym w specyfikacji. Pytanie: Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy związane z szyfrowaniem danych zostały zaimplementowane w programie? Wskazówka: NaleŜy porównać stan obecny (gotowy program) ze specyfikacją. Informacje naleŝy zasięgnąć u projektanta i programisty danego oprogramowania. Test ten moŝe zostać przeprowadzony przez osobę rozwijająca program (programistę). 4.2.5. Zgodność funkcjonalna Celem tego miernika jest sprawdzenie, czy funkcjonalność oprogramowania odpowiada powszechnie stosowanym regulacjom, standardom i konwencjom. NaleŜy sprawdzić, czy wszystkie funkcje z tym związane, które zapisano w specyfikacji (wymaganiach oprogramowania) zostały zaimplementowane w gotowym oprogramowaniu. Miernik ten nie sprawdza, czy wskazana zgodność funkcjonalna oprogramowania została spełniona, a jedynie czy wymagania zapisane w specyfikacji zostały w pełni zastosowane w gotowym systemie (oprogramowaniu). Gotowy program powinien w pełni odpowiadać wymaganiom zdefiniowanym w specyfikacji. Pytanie: Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy zapewniające zgodność funkcjonalną (regulacje, standardy, konwencje) zostały zaimplementowane w programie? Wskazówka: NaleŜy porównać stan obecny (gotowy program) ze specyfikacją. Informacje naleŝy zasięgnąć u projektanta i programisty danego oprogramowania. Test ten moŝe zostać przeprowadzony przez osobę rozwijająca program (programista) lub osobę definiującą wymagania systemu Politechnika Wrocławska, Wrocław 2007 21

Tabela 4 Zewnętrzne i wewnętrzne wymiary bezpieczeństwa. Opracowanie własne. M Lp. Miernik Pytanie Czy kluczowe? Ocena (0/1) Waga punktowa Wynik Udział procentowy MIERNIKI ZEWNĘTRZNE 1. Audyt dostępu 2. Kontrola dostępu Czy wszystkie próby dostępu do danych są rejestrowane w dzienniku zdarzeń? Czy wszystkie (znane, wcześniej zdefiniowane) próby nielegalnego dostępu do danych są rejestrowane w dzienniku zdarzeń? Tak 50 7,5% Tak 50 7,5% BEZPIECZEŃSTWO = 670 pkt 3. 4. 5. Zapobieganie utracie danych Zapobieganie utracie danych Zapobieganie utracie danych Czy pracownik lub osoba zewnętrzna ma moŝliwość celowego zniszczenia danych lub nośników, na których te dane są przechowywane? Czy oprogramowanie jest podatne na przypadkowe skasowanie lub zniszczenie danych? Czy uŝytkownik, korzystając z dostępnych funkcji moŝe nieświadomie i w sposób niezamierzony skasować lub zniszczyć dane? Czy w firmie zastosowano moŝliwie najlepsze urządzenia gwarantujące bezpieczeństwo przechowywania danych? Tak 70 10,4% Tak 70 10,4% Nie 40 6% 6. Zapobieganie utracie danych Czy wykonywany jest regularna (kaŝdego dnia lub częściej) kopia zapasowa (backup) danych? Tak 50 7,5% 7. Zapobieganie utracie danych Czy oprogramowanie umoŝliwia łatwe i skuteczne wykonywanie i odtwarzanie danych z kopii zapasowych? Tak 50 7,5% Politechnika Wrocławska, Wrocław 2007 22

M Lp. Miernik Pytanie Czy kluczowe? Ocena (0/1) Waga punktowa Wynik Udział procentowy 8. Zapobieganie utracie danych Czy stosowane są mechanizmy replikacji danych na dwóch lub więcej niezaleŝnych dyskach twardych? Nie 30 4,5% 9. Zapobieganie utracie danych Czy testowane oprogramowanie umoŝliwia zastosowanie mechanizmów replikacji? Nie 30 4,5% MIERNIKI WEWNĘTRZNE 10. Audyt dostępu Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy związane z rejestrowaniem w dzienniku zdarzeń prób dostępu do danych zostały zaimplementowane w badanej wersji programie? Tak 50 7,5% 11. Kontrola dostępu Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy związane z rejestrowaniem w dzienniku zdarzeń nielegalnych prób dostępu do danych zostały zaimplementowane w programie? Tak 50 7,5% BEZPIECZEŃSTWO = 670 pkt 12. 13. 14. Zapobieganie utracie danych Szyfrowanie danych Zgodność funkcjonalna Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy związane z zapobieganiem utracie danych zostały zaimplementowane w programie? Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy związane z szyfrowaniem danych zostały zaimplementowane w programie? Czy wszystkie zapisane w specyfikacji oprogramowania mechanizmy zapewniające zgodność funkcjonalną (regulacje, standardy, konwencje) zostały zaimplementowane w programie? Tak 50 7,5% Tak 40 6% Tak 40 6% Politechnika Wrocławska, Wrocław 2007 23

V. Funkcjonalność wg ISO 9126. ZGODNOŚĆ V.1. Mierniki zewnętrzne Oceniając zgodność systemu naleŝy przede wszystkim sięgnąć do specyfikacji systemu opracowanej na podstawie wymagań uŝytkowników, do projektu systemu oraz specyfikacji testów oraz ich rezultatów. Oprócz dokumentacji źródłem wiedzy mogą być wywiady przeprowadzone wśród uŝytkowników, to oni bowiem są w stanie najlepiej ocenić funkcjonalność systemu, którym posługują się na co dzień. Osobami weryfikującymi zgodność są dostawca oraz uŝytkownik końcowy. Dostawca sprawdza zgodność na podstawie rezultatów przeprowadzonych testów. UŜytkownik takŝe dokonuje walidacji systemu. Testowanie opiera się na zasadzie czarnej skrzynki i polega jedynie na obserwacji wejść oraz wyjść z systemu. Dzieję się tak dlatego, Ŝe testerami zgodności są zazwyczaj nie programiści a niezaleŝni uŝytkownicy, są oni w stanie w sposób obiektywny ocenić istnienie poszczególnych funkcji. Podobnie jak w przypadku pozostałych mierników, orzekanie o zgodności systemu jest kwestia sporną. Aby model słuŝący do oceny zgodności był uŝyteczny musi w przejrzysty sposób wskazywać czy system jest oceniony pozytywnie tylko wówczas, kiedy spełnia wymagania w 100 % czy jest dopuszczalny powyŝej pewnej granicy. Standardy opisane w róŝnych normach jakościowych definiują zgodność na róŝne sposoby, przykładowo: jako spełnienie przez produkt, proces lub usługę wszystkich odpowiednich wymagań zgodności (100%), jako wymaganie wyraŝone w standardzie podstawowym, które identyfikuje określone wymaganie w sposób skończony, mierzalny i jednoznaczny (wskazuje na opcjonalność niektórych zgodności). 5.1.1. Zgodność funkcjonalna Ten miernik pozwala ocenić czy oprogramowanie jest adekwatne do wymagań uŝytkownika, czy spełnia warunki zawarte w specyfikacji lub jakich obecność jest zwyczajowa dla tego rodzaju oprogramowania (jest standardem). A więc czy zaimplementowano wszystkie funkcjonalności, jakich zaŝyczył sobie klient oraz te, które są wymagane z racji obowiązującego prawa oraz innych standardów. JeŜeli uŝytkownicy korzystający z systemu nie odnajdą w nim podstawowych funkcjonalności uznają go za bezuŝyteczny. Pytanie: Czy system jest zgodny z Ustawą o rachunkowości? Odpowiedź: Tak(1) lub Nie(0) Czy kluczowe: Tak Pytanie: Czy system jest zgodny z polskim prawem podatkowym? Odpowiedź: Tak(1) lub Nie(0) Czy kluczowe: Tak Wskazówka: Jednym z wymogów funkcjonalnych jest to, aby system pozwalał rozliczać się z bieŝącej działalności w sposób zgodny z polskim ustawodawstwem. Pytanie: Czy w systemie obecne są wszystkie funkcjonalności wymagane przez klienta? (rozumiane przykładowo jako moduły pt. finanse, produkcja, magazyn) Odpowiedź: Tak(1) lub Nie(0) Czy kluczowe: Tak Pytanie: Czy system posiada Ŝądane przez klienta wersje językowe? Odpowiedź: Tak(1) lub Nie(0) Czy kluczowe: Tak Politechnika Wrocławska, Wrocław 2007 24

Wskazówka: Zgodność funkcjonalna jest na poziomie mierników zewnętrznych oparta na zasadzie czarnej skrzynki, która pokazuje, Ŝe implementacja spełnia wymagania przedstawione w specyfikacji, a więc te które zostały zdefiniowane przez uŝytkowników. 5.1.2. Standardy zgodności interfejsów Drugim wymiarem słuŝącym do oceny zgodności jest interfejs. SłuŜy on do bezpośredniej interakcji z systemem, a więc nawiązując do wspomnianych wyŝej testów o charakterze czarnej skrzynki odbiera od uŝytkownika informacje na wejściu a następnie zwraca przetworzone dane na wyjściu. Pytanie: Czy interfejs jest zgodny ze specyfikacją oraz powszechnie znanymi standardami, regulacjami i konwencjami? Odpowiedź: Tak(1) lub Nie(0) Czy kluczowe: Nie Wskazówka: Oceny zgodnie z wytycznymi zwartymi w normie dokonuje projektant na podstawie specyfikacji oraz standardów, regulacji czy konwencji. Pytanie: Czy interfejs systemu spełnia oczekiwania uŝytkownika? Czy interfejs jest uznawany przez uŝytkowników za intuicyjny? Odpowiedź: Tak(1) lub Nie(0) Czy kluczowe: Tak Wskazówka: Interfejs musi spełniać oczekiwania uŝytkowników, aby został uzyskany za funkcjonalny. Niezgodność pojawiająca się poprzednim pytaniu nie powinna być uznawana za kluczową, rozbieŝności mogą być rezultatem nieprecyzyjnej specyfikacji lub wręcz nieumiejętnego opisu wymagań przez samych uŝytkowników. Skoro ostatecznie są oni zadowoleni z interfejsu moŝemy uznać, Ŝe spełnia on ich wymagania. Zgodnie z powszechnie obowiązującymi standardami interfejs powinien być ergonomiczny, tak aby był przyjazny dla wszystkich przyszłych uŝytkowników (chodzi tu głównie o takie cechy, które gwarantują swobodę poruszania się i wysoką efektywność). Nie jest to jednak kryterium kluczowe, poniewaŝ nie ergonomiczny interfejs moŝe satysfakcjonować klienta. Pytanie: Czy uŝytkownicy systemu zgłaszają problemy lub czy mają trudności w korzystaniu z interfejsu? Odpowiedź: Tak(1) lub Nie(0) Czy kluczowe: Nie Wskazówka: Trudność w obsłudze nie jest kluczowym czynnikiem pozwalającym na ocenę, poniewaŝ jest wysoce subiektywna, jednak trudność w obsłudze systemu moŝe wynikać z nie intuicyjnego interfejsu, a więc jego funkcjonalnej niezgodności. Pytanie ma na celu zweryfikowanie odpowiedzi na pytanie poprzednie, które zostało uznane za kluczowe. V.2. Mierniki wewnętrzne W przypadku oceny zgodności za pomocą tzw. miar wewnętrznych ewaluacji podlegają kod źródłowy oraz dokumentacja projektowa, natomiast osobami oceniającymi są projektanci i twórcy systemu. Wyniki są oceniane na podstawie zapisanych w dokumentacji wymagań. W zaleŝności od przedmiotu oceny moŝemy tu wyróŝnić trzy zakresy testowania: testowanie protokołów (odbywające się zwykle za pomocą automatów skończonych), testowanie aplikacji (jeŝeli specyfikacja została przedstawiona za pomocą np. notacji UML lub innych moŝliwe jest automatyczne wygenerowanie testów zgodności), testowanie języków oprogramowania, bibliotek oraz API (zautomatyzowanie tych testów jest najtrudniejsze, dodatkowo moŝe wystąpić zjawisko maskowania się błędów, a sprawdzanie za zasadzie czarnej skrzynki oznacza brak moŝliwości wglądu w kod programu). Procedura badawcza przebiega w sposób następujący: 1. Identyfikacja elementów funkcjonalnych w standardzie. Politechnika Wrocławska, Wrocław 2007 25