o
Według normy ISO 8402:
Ogół cech i właściwości wyrobu lub usługi, które
decydują o zdolności wyrobu lub usługi do
zaspokajania stwierdzonych i przewidywanych
potrzeb.
o
Według normy ISO 9000:2001:
Jakość to stopień, w jakim zbiór inherentnych
właściwości spełnia wymagania.
Źródło: Boehm B.W., Software Engineering Economics, Prentice-Hall
Norma
Komitet
techniczny
Tytuł
ISO/IEC 9126-1: 2001
JTC 1
Inżynieria oprogramowania – Model jakości
ISO/IEC 9126-2: 2003
JTC 1
Inżynieria oprogramowania – Jakość zewnętrzna
ISO/IEC 9126-3: 2003
JTC 1
Inżynieria oprogramowania – Jakość wewnętrzna
ISO/IEC 9126-4:2004
JTC 1
Inżynieria oprogramowania – Jakość w użyciu
ISO/IEC 12207:1995
JTC 1
Technologie informacyjne – Cykl życia oprogramowania
ISO/IEC 15504:1998
Części 1–9
JTC 1
Technologie informacyjne – Ocena procesu wytwarzania oprogramowania
PN-EN ISO 9241–1: 2001
TC 159
Wymagania ergonomiczne dotyczące pracy biurowej z zastosowaniem terminali
wyposażonych w monitory ekranowe.
Ogólne wprowadzenie.
ISO/IEC 14598, 1998–
–2001
JTC 1
Technologie informacyjne – Ocena produktu programowego
Modele jakości oprogramowania
Model opublikowany w 1977 roku, opracowany przez McCalla, Richardsa i
Walersa, którzy zidentyfikowali najważniejsze czynniki warunkujące jakość i
dokonali ich podziału według aspektów oprogramowania, których one dotyczą.
W ten sposób powstała koncepcja mówiąca o tym, że ocena oprogramowania
powinna być skoncentrowana na trzech typach charakterystyk jakości:
czynnikach – służących zdefiniowaniu zewnętrznego obrazu oprogramowania z
punktu widzenia użytkowników,
kryteriach – dotyczących czynników produktu programowego, jego budowy i
opisu wewnętrznej struktury z punktu widzenia programisty,
metrykach – których zadaniem jest kontrola realizacji czynników jakości za
pomocą dostarczonej skali i metod pomiaru.
Podejście to zwane jest w języku angielskim Factor Criteria Metric (FCM).
Jakość produktu informatycznego jest opisywana
jako trójkąt, w którego wierzchołkach umieszczono
atrybuty jakości, przypisane do kategorii:
łatwość dostosowywania do zmiennego środowiska,
podatność na zmiany,
sposób działania.
Poprawność - stopień realizacji wymagań, kompletności i logiczności
wdrożenia, zgodności działania programu ze specyfikacją,
Niezawodność - stopień, w jakim program jest odporny na błędy i zdolny,
by na nie zareagować w sposób zrozumiały
Wydajność - wyraża ilość obliczeń wykonanych w określonym czasie,
Integralność - zdolność kontrolowania dostępu osób niepożądanych do
funkcjonowania programu,
Użyteczność - wysiłek, jakiego wymaga nauka obsługi programu,
przygotowania danych wejściowych oraz interpretacji danych na
wyjściach.
Pielęgnowalność - stopień przystosowania programu do działań
zmierzających do jego poprawy, modyfikacji, rozszerzenia, adaptacji itp.,
Elastyczność - możliwość rozbudowy o nowo zdefiniowane funkcje
(miara uniwersalności rozwiązania),
Testowalność – stopień, w jakim program jest przyjazny dla testera (czy
jego struktura, dokumentacja, specyfikacje dotyczące modułów są
przejrzyste).
Przenośność - możliwość uruchomienia oprogramowania na różnych
maszynach, o różnych parametrach systemowych,
Współdziałanie - zdolność do współpracy z innym oprogramowaniem
poprzez wymianę danych,
Możliwość ponownego użycia - możliwość wykorzystania fragmentów
oprogramowania przy tworzeniu innych aplikacji, w zależności od
struktury tego oprogramowania i realizowanych funkcji.
Model Boehma powstał w 1978 roku. Zawiera inny, w stosunku do
modelu McCalla, zbiór cech oraz ich definicji.
Podstawowymi cechami jakości są:
przydatność,
przenośność,
łatwość konserwacji.
Czynniki FURPS stanowiły elementy listy kontrolnej wykorzystywanej na
potrzeby firmy Hewlett-Packard.
Jest to model, w którym uwzględniono funkcjonalność jako atrybut
jakości.
Skrót FURPS pochodzi od angielskich słów:
Functionality (funkcjonalność)
Usability (użyteczność)
Reliability (niezawodność)
Performance (wydajność)
Supportability (jakość wsparcia).
Prace nad zdefiniowaniem standardu jakości dla oprogramowania
prowadzono od roku 1985. W efekcie 6-letnich prac, opublikowano
normę poświęconą wyłącznie problematyce jakości oprogramowania
(ISO 9126:1991).
Norma ta opiera się na podejściu zorientowanym na ocenę jakości z
wykorzystaniem metryk (Software Quality Metrics). Zawarte w niej
charakterystyki jakości mają wyłącznie charakter informacyjny, dlatego
wkrótce po publikacji podjęto prace nad jej rozwinięciem.
W 2001 roku opublikowano normę ISO/IEC 9126:2001 stanowiącą
rewizję starej normy. Dodatkowo w 2003 i 2004 roku opublikowano trzy
standardy pod tym samym numerem, będące rozwinięciem modelu
zaprezentowanego w części pierwszej.
ISO/IEC 9126 Software engineering - Product
quality
o
Part 1: Quality model
o
Part 2: External metrics
o
Part 3: Internal metrics
o
Part 4: Quality in use metrics
ISO/IEC 14598: Information technology -- Software
product evaluation
o
Part 1: General overview
o
Part 2: Planning and management
o
Part 3: Process for developers
o
Part 4: Process for acquirers
o
Part 5: Process for evaluators
o
Part 6: Documentation of evaluation modules
Norma
ISO/IEC 9126
Model jakości wewnętrznej
oraz zewnętrznej
Użyteczność
Skuteczność
Niezawodność
Utrzymywalność
Funkcjonalność
Przenaszalność
Odpowiedniość
Dokładność
Współdziałanie
Bezpieczeństwo
Zgodność
funkcjonalna
Dojrzałość
Tolerancja na
błędy
Odzyskiwalność
Zgodność
niezawodności
Zrozumiałość
Szybkość
uczenia
Operacyjność
Atrakcyjność
Zgodność
użyczetności
Wykorzystanie
zasobów
Zgodność
skuteczności
Czas reakcji
Stabilność
Testowalność
Możliwość
modyfikacji
Zdolność
utrzymania
Możliwość
analizy
Koegzystencja
Zastępowalność
Możliwość
instalacji
Zdolność do
przenoszenia
Zdolność do
adaptacji
Charakterystyka
Pytania
Funkcjonalność
1. Czy oprogramowanie realizuje zadania w odpowiedni sposób?
2. Czy uzyskane rezultaty są zgodne z oczekiwaniami?
3. Czy system współdziała z innymi systemami?
4. Czy oprogramowanie posiada skuteczne mechanizmy autoryzacji?
Niezawodność
1. Czy oprogramowanie potrafi odpowiednio zareagować na wystąpienie błędu?
2. Czy oprogramowanie kontynuuje pracę oraz daje możliwość odzyskania informacji po wystąpieniu błędu?
3. Czy większość błędów została wykryta i usunięta podczas rozwoju oprogramowania?
Użyteczność
1. Czy użytkownik uważa oprogramowanie za łatwe w obsłudze?
2. Czy użytkownik szybko uczy się obsługi oprogramowania?
3. Czy obsługa systemu wymaga dużego wysiłku użytkownika?
4. Czy interfejs jest przyjazny użytkownikowi?
Skuteczność
1. Jak szybko oprogramowanie reaguje na polecenia użytkownika?
2. W jaki sposób oprogramowanie wykorzystuje zasoby?
Utrzymywalność
1. Czy łatwo jest zdiagnozować błędy?
2. Czy zmodyfikowanie oprogramowania sprawia trudności?
3. Czy wprowadzenie zmian wpływa na dotychczasową funkcjonalność?
4. Czy łatwo jest przetestować oprogramowanie?
Przenaszalność
1. Czy oprogramowanie może zostać przeniesione do innego środowiska?
2. Czy oprogramowanie jest zgodne ze standardami dotyczącymi przenaszalności?
3. Czy dane oprogramowanie może zastąpić inne?
4. Czy instalacja oprogramowania sprawia trudności?
Jakość użytkowa
Produktywność
Bezpieczeństwo
Wydajność
Satysfakcja
Charakterystyka
Pytanie
Wydajność
1. Ile z założonych celi jest osiągane?
2. Jaka jest częstotliwość pojawienia się błędu?
3. Jaki procent z całkowitej ilości rozpoczętych działań zostaje doprowadzony do końca?
Produktywność
1. Ile czasu zajmuje wykonanie określonej czynności, przetworzenie informacji wejściowej przez
oprogramowanie?
2. Jak produktywni są użytkownicy oprogramowania (liczba zadań ukończonych w danej jednostce czasu)?
3. Jakie koszty generują użytkownicy wykorzystujący oprogramowanie?
4. Jaka jest wydajność użytkownika w porównaniu z wydajnością eksperta?
Bezpieczeństwo
1. Czy wykorzystanie danego oprogramowania ma wpływ na zdrowie i komfort pracy użytkownika?
2. Jaka często oprogramowanie powoduje straty finansowe?
3. Jaka jest częstotliwość awarii systemu?
Satysfakcja
1. W jakim stopniu użytkownik jest usatysfakcjonowany korzystaniem z oprogramowania?
2. W jakim stopniu możliwości oprogramowania satysfakcjonują jego użytkownika?
3. Jaka liczba potencjalnych użytkowników zdecyduje się wykorzystać dane oprogramowanie?
Jakość wewnętrzna to zbiór atrybutów oprogramowania, które wpływają
na jego zdolność do spełnienia w konkretnej sytuacji zarówno tych
ukrytych, jak i jasno sprecyzowanych potrzeb użytkowników [ISO/IEC
9126:2003-3, s. 58].
Wewnętrzne mierniki jakości mają swoje zastosowanie w przypadku
analizy oprogramowania będącego wciąż na etapie rozwoju i nie dotyczą
samodzielnego, wykonywalnego programu.
Informacje wejściowe w procesie oceny jakości wewnętrznej pochodzą z
rewizji kodów źródłowych, projektu, specyfikacji technicznej, a także
oszacowań dotyczących parametrów oprogramowania, konfiguracji
systemu kontroli czy dzienników systemowych.
Badanie jakości na tym etapie pozwala przewidzieć jakość produktu
końcowego i daje szansę na podjęcie działań naprawczych
podnoszących tę jakość.
Jakość zewnętrzna to stopień w jakim produkt odpowiadana
postawionym i zaimplementowanym potrzebom, podczas użytkowania w
określonych warunkach [ISO/IEC 9126:2003-2, s. 85].
Kluczowe znaczenie odgrywa jakość efektów działania, której oceny
można
dokonać
bez
znajomości
mechanizmów,
algorytmów
przetwarzania i wewnętrznej struktury programu
Docelowymi odbiorcami metryk jakości zewnętrznej są:
nabywcy
(jednostki
lub
organizacje,
które
nabywają
system,
oprogramowanie lub też usługę programową od dostawcy),
oceniający (jednostki lub organizacje dokonujące oceny, a więc
przykładowo zespoły testujące, działy jakości z menedżerami jakości,
organizacje rządowe lub użytkownicy),
deweloperzy, którzy zajmują się rozwojem oprogramowania, włączając
analizę wymagań, projektowanie oraz testowanie we wszystkich etapach
cyklu życia produktu,
programiści oraz wszyscy zajmujący się utrzymywaniem i obsługą
programu,
dostawcy oraz użytkownicy.
Jakość w użyciu to zdolność produktu do umożliwienia użytkownikom
osiągnięcia określonych celów w sposób efektywny, produktywny,
bezpieczny i satysfakcjonujący, podczas użytkowania w określonych
warunkach [ISO/IEC 9126:2003-3, s. 58].
Jakość użytkowa, jako jeden z wymiarów jakości, powinna być
analizowana jedynie w ścisłym powiązaniu z rzeczywistym środowiskiem
systemowym, w którym funkcjonuje produkt programowy.
Krok 1. Zidentyfikowanie wymagań jakościowych.
Krok 2. Identyfikacja celu oceny oprogramowania.
Krok 3. Przygotowanie planu zapewniania jakości oraz
stworzenie harmonogramu raportowania.
Krok 4. Uszczegółowienie modelu oceny.
Krok 5. Zaprojektowanie procesu oceny.
Krok 6. Dokonanie oceny oraz analiza wyników.
Krok 7. Przedstawienie rezultatów oceny.
(kroki 4-7 powinny odbywać się w iteracjach, za każdym razem,
gdy realizowany jest inny proces w organizacji lub oceniany jest
inny komponent)
Krok 8. Doskonalenie procesu wytwarzania
oprogramowania.
Testowanie
Analiza wymagań
użytkownika
Testy akceptacyjne
użytkowników
Testowanie całego
systemu
Definiowanie wymagań produktu
Testowanie integracji
Testowanie modułów
Projektowanie architektury
Kodowanie
Testy kodów
Szczegółowe
projektowanie
PLAN
TESTÓW
Po co?
Co?
Jak?
Kto?
Jak długo?
Kiedy?
Jak?
Dla kogo?
CEL
PRZEDMIOT
OCENY
TECHNIKA
OSOBA
ODPOWIEDZIALNA
WARUNEK
KOŃCOWY
OGRANICZENIA
GROMADZENIE
DANYCH
REZULTAT
Faza cyklu życia
oprogramowania
Obiekt
Technika oceny
Charakter
Procedury
Narzędzia
Osoba
Analiza wymagań
Specyfikacja
Kompletność wymagań
Inspekcja
Przegląd
Wywiady
Analityk biznesowy
Konsultant
Projektowanie
architektury
Projekt architektury
Inspekcja
Przegląd
statyczny
strukturalny
Lista kontrolna
Analityk biznesowy
Projektant
Szczegółowe
projektowanie
oprogramowania
Przypadki użycia
Model biznesowy
Prototyp
Inspekcja
Przegląd projektów
statyczny
strukturalny
Lista kontrolna
Projektant
Pisanie kodu
i testowanie
Kod źródłowy
Procedury
Inspekcja
Przegląd kodu (walkthrough)
Testy strukturalne
(testy zautomatyzowane)
statyczny
strukturalny
Lista kontrolna
Debugger
Analizator pokrycia kodu
Programista
Moduł
Struktura danych
Przyrostowe testowanie
iteracyjne
dynamiczny
Analizator pokrycia kodu
Programista
Testowanie modułów
i integracja w
podsystemy
Podsystem
Testy integracyjne
testowanie interfejsu
dynamiczny
funkcjonalny
Narzędzia do
automatycznego testowania
Projektant
Tester
Integracja modułów
systemu
Zintegrowane moduły
i podsystemy
Architektura
Interfejs
Inspekcja
Przegląd
Testy integracyjne
Testowanie interfejsu
dynamiczny
funkcjonalny
Narzędzia do
automatycznego testowania
Tester
Konsultant
Testowanie programu
Produkt programowy
Dokumentacja
Zatwierdzanie
Testy akceptacyjne
Audyt konfiguracji
Testy systemowe
(obciążeniowe)
statyczny
dynamiczny
Procedury zatwierdzania
Narzędzia do
automatycznego testowania
Tester
Użytkownik
Konsultant
Instalacja
oprogramowania
System
Sprzęt
Oprogramowanie
Testy systemowe
(obciążeniowe)
dynamiczny
Narzędzia do
automatycznego testowania
Osoba wdrażająca
Wspieranie
Oprogramowanie
Wydajność
Użycie zasobów
Przenaszalność
statyczny
dynamiczny
Narzędzia do
automatycznego testowania
Konsultant techniczny