Atrybuty jakości
Organizacje rozwijające systemy do zastosowań krytycznych (o których była mowa na wstępie) są odpowiedzialne za zidentyfikowanie wymagań i za przydzielenie odpowiednich zasobów (np. procesorów czy sieci komunikacyjnych). Nie wystarcza jedynie sprostać funkcjonalnym wymaganiom. Systemy krytyczne muszą spełniać także takie wymagania jak: bezpieczeństwo, moc czy niezawodność.
Różnorodne zagadnienia problematyki jakości oraz różne definicje jakości
Mnogość definicji jakości została w omówiona w ogólnym, obiektywnym podejściu w [Fleurquin 98]. Niniejszy podrozdział zawiera najważniejsze zagadnienia tam poruszone.
Norma NF ISO 8402 [ISO-8402 94] definiuje pojęcie jakości w następujący sposób:
„zespół własności obiektu, wiążących się z jego zdolnością zaspokajania potrzeb stwierdzonych i oczekiwanych”.
Powyższa definicja rozważa jakość w dwóch aspektach. Po pierwsze należy sprecyzować "czego" jakość jest rozważana, czyli o jaki obiekt chodzi (produkt, usługa, czynność opracowania, itp.), a z drugiej strony "czyje" potrzeby są brane pod uwagę (użytkownika, kierownika projektu, itp.).
Cechy charakterystyczne definiujące jakość nie są w istocie takie same; zależą one od punktu widzenia i będą inne dla użytkownika, programisty, czy klienta-decydenta.
Pierwszy będzie brał pod uwagę własności zewnętrzne dotyczące przede wszystkim widocznych aspektów dostarczonego oprogramowania, takich jak łatwość użycia czy parametry (mówi się tutaj o jakości zewnętrznej oprogramowania).
Drugi wysunie naprzód własności takie jak testowalność lub czytelność kodu projektowanego programu (mówi się tutaj o jakości wewnętrznej oprogramowania).
Trzeci ze swojej strony zainteresuje się własnościami takimi jak termin i koszty realizacji czy też gwarancje zapewnienia jakości deklarowanej przez dostawcę (na przykład świadectwem zgodności z normą ISO 9001). W tym ostatnim przypadku, można zauważyć, że własności definiujące jakość odnoszą się do procesu opracowywania1 oprogramowania a nie do samego produktu finalnego będącego wynikiem tego procesu.
W zależności od nastawienia, jakość może także być definiowana ze względu na:
produkty i usługi: z zewnętrznego punktu widzenia (własności dostarczonego oprogramowania lub oferty oprogramowania2) lub z wewnętrznego (własności oprogramowania na pewnym szczególnym etapie procesu opracowywania, takim jak na przykład dokument specyfikacji) ;
część lub całość procesu opracowywania: z punktu widzenia zewnętrznego (obserwowalność, niezawodność, sterowalność, itp.) lub wewnętrznego (metody, narzędzia, reguły, procedury, standardy, normy, itp.).
Przykłady definicji jakości oprogramowania w literaturze
Różnorodność punktów widzenia pociągająca za sobą różne nastawienie wyjaśnia istnienie wielorakich definicji pojęcia jakości oprogramowania, z którymi można spotkać się w literaturze:
[Bell 92] definiuje jakość w odniesieniu do użytkownika końcowego i dostarczonego oprogramowania. Ściślej, wyjaśnia się, że oprogramowanie spełniające wymagania jakościowe odpowiada wymaganiom użytkowników, jest niezawodne i łatwe w utrzymaniu.
[Norris 92] opisuje bardziej szczegółowo tą definicję i zauważa, że cechy jakościowe produktu jakim jest oprogramowanie dotyczą również bezpieczeństwa, możliwości dostosowania, parametrów, funkcjonalności, niezawodności, oraz łatwości użytkowania.
[Arthur 92] odrzuca zbyt ograniczony charakter definicji odnoszących się wyłącznie do oprogramowania w wersji dostarczonej. Zachowując punkt widzenia klienta i przechodząc na poziom oferty oprogramowania, do poprzednio wspomnianych własności dodane są ograniczenia kosztów i terminów (tak niskie, jak to tylko możliwe i zgodne z oczekiwaniami klientów).
[Babey 95] stwierdza ze swojej strony, że jakość z punktu widzenia programistów polega na zaprojektowaniu rozwiązań programowych zgodnych z wymaganiami użytkowników przy jednoczesnym dotrzymaniu terminów i kosztów opracowania. W tym przypadku jakość opiera się na sprawności procesów opracowywania oprogramowania.
[Maréchal 95] uważa, że jakość w rozumieniu kierownika przedsiębiorstwa dostarczającego jest postrzegana w kategoriach terminów realizacji gotowego oprogramowania, poprawności procesu projektowania, braku reklamacji, itp. Charakterystyki jakości opierają się na zadowoleniu klientów oraz wynikają z przebiegu procesu opracowywania.
Istnieją następujące normy i standardy (rys. 2.1) odnoszące się do przypadku oprogramowania dostarczonego (jakość zewnętrzna), do przypadku rezultatów projektowania (jakość wewnętrzna), do czynności opracowywania, do procesów opracowywania i do systemu jakości3.
Rysunek 2.1. Normy i standardy jakości oprogramowania.
Jakość od strony użytkownika i atrybuty jakości wg normy ISO 9124
Użytkownik nie interesuje się problematyką wewnętrzną i sposobem tworzenia oprogramowania, postrzega natomiast jakość oferty poprzez pryzmat bezpośrednich własności dostarczonego oprogramowania i świadczeń towarzyszących wynikających z umowy (pomoc techniczna, szkolenie, itp.).
Wymagania użytkownika odnoszące się do jakości a dotyczące samego produktu jakim jest oprogramowanie (z pominięciem ew. świadczeń) zostały podzielone w normie ISO 9126 [ISO-9126 92] na 6 własności:
Niezawodność oprogramowania. Obejmuje ona "zespół właściwości odnoszących się do zdolności oprogramowania do utrzymania poziomu usług zgodnego z ustalonymi warunkami i w czasie ustalonego okresu czasu". Z własnością tą łączą się pojęcia takie jak tolerancja błędów, możliwość odtworzenia stanu obliczeń po awarii, częstość awarii.
Łatwość użytkowania. Obejmuje ona "zespół właściwości odnoszących się do wysiłku niezbędnego do użytkowania i do indywidualnej oceny tego użytkowania przez określony jawnie lub domniemany zbiór użytkowników". Z własnością tą łączą się pojęcia takie jak łatwość zrozumienia, łatwość szkolenia i łatwość eksploatacji.
Sprawność. Ta własność obejmuje "zespół właściwości odnoszących się do wzajemnego stosunku pomiędzy poziomem usług świadczonych przez oprogramowanie a wielkością użytkowanych zasobów w określonych warunkach". Z własnością tą łączą się pojęcia takie jak czas odpowiedzi, wielkość użytkowanych zasobów (obszar pamięci, przestrzeń na dysku, sprzęt, użytkowane usługi lub wsparcie logistyczne, itp.).
Zdolność funkcjonalna. Charakteryzuje ona zdolność oprogramowania do zaspokajania potrzeb użytkowników w kategorii usług. Z własnością tą łączą się pojęcia takie jak zdolność oferowania oczekiwanej funkcjonalności, dostarczanie stosownych i dokładnych wyników, interoperacyjność (zdolność wzajemnej współpracy), zgodność z normami czy bezpieczeństwo.
Przenośność. Obejmuje ona "zespół właściwości odnoszących się do zdolności oprogramowania do przenoszenia z jednego środowiska do innego". Z własnością tą łączą się pojęcia takie jak łatwość adaptacji, łatwość instalacji, zgodność z normami i przyjętymi konwencjami, mające związek z możliwością przenoszenia oprogramowania.
Utrzymywalność (Łatwość obsługiwania). Własność ta odnosi się do wysiłku niezbędnego przy wprowadzaniu modyfikacji do oprogramowania. Z własnością tą łączą się pojęcia takie jak: łatwość analizy oprogramowania, łatwość modyfikacji, stabilność oprogramowania przy modyfikacjach czy łatwość testowania.
W dalszej części pracy dokonana zostanie klasyfikacja powyższych własności według grup atrybutów.
Jak różne środowiska odbierają atrybuty jakości
Istnieją różne szkoły (opinie, tradycje) odnoszące się do systemów krytycznych. Szkoły te zwracaja szczególną uwagę na różne atrybuty jakości:
moc - z tradycji systemów czasu rzeczywistego i planowania wydajności,
niezawodność – z tradycji ultra-niezawodnych i tolerancyjnych na awarie systemów,
bezpieczeństwo - z tradycji środowisk rządowych, bankowych i akademickich, analizy hazardów i inżynierii bezpiecznych systemów.
System często nie spełnia potrzeb użytkowników (brak jakości), jeśli projektanci zbyt wąsko (w ograniczony sposób) koncentrowali się na spełnianiu pewnych wymagań, nie biorąc pod uwagę wpływu innych wymagań albo biorąc je pod uwagę zbyt późno w procesie rozwoju. Przykładowo, może nie być możliwym spełnienie dwóch kryteriów jednocześnie. Zagadnienie to podlega pod problem optymalizacji wielokryterialnej, który został już dość dobrze poznany, gdyż zajmowano się nim od dawna.
Wyznaczenie ogólnej metryki dla jakości oprogramowania jest sprawą problematyczną. Zasadniczym problemem jest to, że indywidualne właściwości jakości pozostają ze sobą często w konflikcie. Zwiększenie wydajności często odbywa się kosztem przenośności, dokładności i zrozumiałości; zwiększenie dokładności często rodzi problemy z przenośnością, zwięzłość koliduje z czytelnością. Użytkownicy często mają trudności z wyznaczeniem swoich preferencji w takich konfliktowych sytuacjach [Boehm 78].
Kompromisy pomiędzy atrybutami jakości
Projektanci potrzebują analizy kompromisów pomiędzy różnorakimi kolidującymi atrybutami. Ostatecznym celem jest zdolność ilościowego oszacowania różnorakich atrybutów jakości, osiągając w efekcie lepiej działający system. Nie powinniśmy szukać jednej uniwersalnej metryki, ale starać się wyznaczyć udział (ilość) indywidualnych atrybutów osiągając kompromis pomiędzy tymi metrykami, zaczynając od opisu architektury oprogramowania.
Rodzajowa klasyfikacja atrybutów jakości.
Atrybuty, to inaczej cechy (właściwości) funkcjonalne dostarczane przez system użytkownikom. Inaczej mówiąc, można to określić jako zachowanie się systemu odbierane (odczuwane) przez użytkowników. Użytkownikiem jest inny system (fizyczny albo ludzki), który wzajemnie oddziałuje z wyżej wymienionym [Laprie 92]. Zachowanie jest inicjowane pewnym wydarzeniem czy sygnałem, który jest bodźcem dla systemu sygnalizując potrzebę określonej reakcji. Bodziec ten może pochodzić tak z wnętrza systemu, jak i spoza systemu.
Rysunek 2.2. Rodzajowa systematyka atrybutów jakości
Dla każdego atrybutu jakości (grupy atrybutów mocy, niezawodności, bezpieczeństwa i zabezpieczeń) stosujemy klasyfikację (rys 2.2), która określa:
Związki (concerns) – parametry, przez które oceniane są atrybuty systemu, są one wyszczególnione i mierzone.
Specyficzne składniki atrybutów – parametry systemu (takie jak polityka i mechanizmy wbudowane w system) i ich otoczenie, mające wpływ na związki. W zależności od atrybutów, składniki specyficzne atrybutów są zewnętrznymi albo wewnętrznymi cechami oddziaływującymi na związki. Składniki te mogą być od siebie niezależne albo mogą pozostawać w zależności przyczyna / efekt. Składniki i ich relacje mogą być włączone do architektury systemu:
Składniki mocy – aspekty systemu przyczyniające się do mocy. Zawierają one żądania od otoczenia i odpowiedzi systemu na te żądania.
Osłabianie niezawodności – składniki systemu, które mogą przyczyniać się do braku niezawodności. Istnieje pewien łańcuch powiązań między błędami wewnątrz systemu i awariami widzianymi przez otoczenie. Wady i usterki powodują błędy; błąd jest stanem systemu, który może prowadzić do awarii.
Składniki bezpieczeństwa – aspekty systemu, które przyczyniają się do bezpieczeństwa. Powyższe zawierają cechy interfejsu systemu / otoczenia jak i cechy takie jak np. enkapsulacja.
Osłabienie zabezpieczeń – aspekty systemu przyczyniające się do (braku) pewności. Punkty ryzyka są warunkami systemu, które mogą prowadzić do niepowodzenia lub wypadku. Niepowodzenia są niezaplanowanymi zdarzeniami przynoszącymi niepożądane konsekwencje.
Metody – jak odnosimy się do związków: analiza i synteza procesów podczas rozwoju systemu oraz procedury i szkolenia dla użytkowników i operatorów. Metody mogą być używane do analizy, syntezy, procedur, szkoleń, czy procedur używanych w czasie rozwoju i działania.
komentarze
Copyright © 2008-2010 EPrace oraz autorzy prac.