



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