ð
ð
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.
y
ródło: Boehm B.W., Software Engineering Economics, Prentice-Hall
Komitet
Norma Tytuł
techniczny
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
JTC 1 Technologie informacyjne  Ocena procesu wytwarzania oprogramowania
Części 1 9
Wymagania ergonomiczne dotyczÄ…ce pracy biurowej z zastosowaniem terminali
PN-EN ISO 9241 1: 2001 TC 159
wyposażonych w monitory ekranowe. Ogólne wprowadzenie.
ISO/IEC 14598, 1998
JTC 1 Technologie informacyjne  Ocena produktu programowego
 2001
ð
ð
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
Funkcjonalność Niezawodność Użyteczność Skuteczność Utrzymywalność Przenaszalność
Odpowiedniość Dojrzałość Zrozumiałość Czas reakcji Możliwość Zdolność do
analizy adaptacji
Szybkość
Dokładność Tolerancja na Wykorzystanie Możliwość Możliwość
uczenia
błędy zasobów modyfikacji instalacji
Operacyjność
Współdziałanie Odzyskiwalność Zgodność Stabilność Koegzystencja
Atrakcyjność
skuteczności
Bezpieczeństwo Zgodność Testowalność Zastępowalność
Zgodność
niezawodności
użyczetności
Zgodność Zdolność Zdolność do
funkcjonalna utrzymania przenoszenia
Charakterystyka Pytania
1. Czy oprogramowanie realizuje zadania w odpowiedni sposób?
2. Czy uzyskane rezultaty sÄ… zgodne z oczekiwaniami?
Funkcjonalność
3. Czy system współdziała z innymi systemami?
4. Czy oprogramowanie posiada skuteczne mechanizmy autoryzacji?
1. Czy oprogramowanie potrafi odpowiednio zareagować na wystąpienie błędu?
Niezawodność 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?
1. Czy użytkownik uważa oprogramowanie za łatwe w obsłudze?
2. Czy użytkownik szybko uczy się obsługi oprogramowania?
Użyteczność
3. Czy obsługa systemu wymaga dużego wysiłku użytkownika?
4. Czy interfejs jest przyjazny użytkownikowi?
1. Jak szybko oprogramowanie reaguje na polecenia użytkownika?
Skuteczność
2. W jaki sposób oprogramowanie wykorzystuje zasoby?
1. Czy łatwo jest zdiagnozować błędy?
2. Czy zmodyfikowanie oprogramowania sprawia trudności?
Utrzymywalność
3. Czy wprowadzenie zmian wpływa na dotychczasową funkcjonalność?
4. Czy łatwo jest przetestować oprogramowanie?
1. Czy oprogramowanie może zostać przeniesione do innego środowiska?
2. Czy oprogramowanie jest zgodne ze standardami dotyczącymi przenaszalności?
Przenaszalność
3. Czy dane oprogramowanie może zastąpić inne?
4. Czy instalacja oprogramowania sprawia trudności?
Jakość użytkowa
Wydajność Produktywność Bezpieczeństwo Satysfakcja
Charakterystyka Pytanie
1. Ile z założonych celi jest osiągane?
Wydajność 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?
1. Ile czasu zajmuje wykonanie określonej czynności, przetworzenie informacji wejściowej przez
oprogramowanie?
Produktywność 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?
1. Czy wykorzystanie danego oprogramowania ma wpływ na zdrowie i komfort pracy użytkownika?
Bezpieczeństwo 2. Jaka często oprogramowanie powoduje straty finansowe?
3. Jaka jest częstotliwość awarii systemu?
1. W jakim stopniu użytkownik jest usatysfakcjonowany korzystaniem z oprogramowania?
Satysfakcja 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 z
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ń Testy akceptacyjne
użytkownika użytkowników
Definiowanie wymagań produktu Testowanie całego
systemu
Projektowanie architektury Testowanie integracji
Szczegółowe Testowanie modułów
projektowanie
Kodowanie
Testy kodów
Po co?
Dla kogo?
CEL Co?
PRZEDMIOT
REZULTAT
OCENY
PLAN
GROMADZENIE
TECHNIKA
Jak? Jak?
DANYCH
TESTÓW
OSOBA
OGRANICZENIA
ODPOWIEDZIALNA
WARUNEK
Kiedy? Kto?
KOC
COWY
Jak długo?
Faza cyklu życia Procedury
Obiekt Technika oceny Charakter Osoba
oprogramowania Narzędzia
Specyfikacja Inspekcja Analityk biznesowy
Analiza wymagań Wywiady
Kompletność wymagań Przegląd Konsultant
Projektowanie Inspekcja statyczny Analityk biznesowy
Projekt architektury Lista kontrolna
architektury PrzeglÄ…d strukturalny Projektant
Szczegółowe Przypadki użycia
Inspekcja statyczny
projektowanie Model biznesowy Lista kontrolna Projektant
Przegląd projektów strukturalny
oprogramowania Prototyp
Inspekcja
Lista kontrolna
Pisanie kodu Kod z
ródłowy Przegląd kodu (walkthrough) statyczny
Debugger Programista
i testowanie Procedury Testy strukturalne strukturalny
Analizator pokrycia kodu
(testy zautomatyzowane)
Moduł Przyrostowe testowanie Programista
Testowanie modułów dynamiczny Analizator pokrycia kodu
Struktura danych iteracyjne
i integracja w
Testy integracyjne dynamiczny Narzędzia do Projektant
podsystemy Podsystem
testowanie interfejsu funkcjonalny automatycznego testowania Tester
Zintegrowane moduły Inspekcja
Integracja modułów
i podsystemy Przegląd dynamiczny Narzędzia do Tester
systemu
Architektura Testy integracyjne funkcjonalny automatycznego testowania Konsultant
Interfejs Testowanie interfejsu
Zatwierdzanie
Tester
Produkt programowy Testy akceptacyjne Procedury zatwierdzania
statyczny Użytkownik
Testowanie programu Dokumentacja Audyt konfiguracji Narzędzia do
dynamiczny Konsultant
Testy systemowe automatycznego testowania
(obciążeniowe)
System
Instalacja Testy systemowe Narzędzia do
Sprzęt dynamiczny Osoba wdrażająca
oprogramowania (obciążeniowe) automatycznego testowania
Oprogramowanie
Wydajność
Oprogramowanie statyczny Narzędzia do
Wspieranie Użycie zasobów Konsultant techniczny
dynamiczny automatycznego testowania
Przenaszalność