Podstawowe problemy mierzenia jakości w inżynierii oprogramowania

Pełen tekst

(1)Zeszyty Naukowe nr 814. 2010. Uniwersytetu Ekonomicznego w Krakowie. Dariusz Dymek Katedra Systemów Obliczeniowych. Podstawowe problemy mierzenia jakości w inżynierii oprogramowania Streszczenie. Problem jakości oprogramowania komputerowego i jej pomiaru jest niedoceniany w środowisku twórców oprogramowania. Niemniej jednak coraz większe wymagania użytkowników oraz rola oprogramowania komputerowego w życiu codziennym sprawiają, że problem ten jest coraz częściej dostrzegany. Niniejsza praca przybliża aktualny stan wiedzy w dziedzinie jakości oprogramowania i przedstawia podstawowe problemy związane z mierzeniem jakości oprogramowania. Słowa kluczowe: modele jakości oprogramowania, mierzenie jakości oprogramowania.. 1. Wprowadzenie Szybki rozwój technologii komputerowej rozpoczęty w latach 70. XX w. sprawił, że chociaż oprogramowanie komputerowe jest jednym z najmłodszych produktów ludzkiej działalności, jego rola w obecnym świecie jest nie do przecenienia i trudno wyobrazić sobie funkcjonowanie współczesnego społeczeństwa bez wykorzystania komputerów i oprogramowania komputerowego. Zapewnienie wysokiej jakości tych elementów staje się jednym z bardzo ważnych problemów, z jakimi muszą się zmierzyć wszyscy ich twórcy. Producenci sprzętu komputerowego stają przed stosunkowo prostym zadaniem, gdyż komputery są po prostu urządzeniami elektronicznymi, chociaż jednymi z najbardziej skomplikowanych. Oznacza to, że w przypadku komputerów możliwe jest wykorzystanie wszystkich doświadczeń związanych z zapewnieniem jakości w przemyśle elektronicznym. Stale rosnący poziom niezawodności sprzętu komputerowego świadczy o skuteczności tych działań. Z odmienną sytuacją mamy do czynienia w kwestii oprogramowania komputerowego. Jego niematerialny i niepowtarzalny1 charakter spra1. Oprogramowanie komputerowe jest wynikiem pracy twórczej człowieka i zależy od jego cech, nawyków i przyzwyczajeń, a nawet chwilowego samopoczucia [Turski 1978]. Większość metodyk.

(2) 6. Dariusz Dymek. wia, że konieczne stało się wypracowanie nowych lub znaczne zmodyfikowanie istniejących sposobów i metod działania w zakresie zapewniania jakości. Aby móc zapewnić wysoką jakość oprogramowania komputerowego, musimy dysponować wydajnymi metodami sterowania procesem jego tworzenia, do czego konieczne są obiektywne mierniki pozwalające jednoznacznie określać zarówno jakość produktu, jakim jest oprogramowanie komputerowe, jak i jakość procesu jego tworzenia. Te dwa aspekty: jakość produktu i jakość procesu są podstawą nowoczesnego podejścia do problematyki jakości w inżynierii oprogramowania. Jakość programu komputerowego jest opisywana przez zestaw właściwości oprogramowania, tworzących model jakości oprogramowania komputerowego. Krótką charakterystykę tych modeli zawiera punkt 2. W kolejnym zaprezentowano aktualny stan wiedzy w zakresie możliwości mierzenia poziomu jakości oprogramowania. Mierzenie jakości procesu tworzenia oprogramowania nie odbiega w swojej istocie od podobnych zagadnień opartych na podejściu projektowym w innych dziedzinach, choć w wielu przypadkach wymaga wykorzystania specyficznych dla oprogramowania komputerowego miar. Zagadnienie to zostało omówione w punkcie 3. W następnym zaprezentowano zasady budowy systemu miar (software measurement framework) integrujących te dwa aspekty i pozwalających spełnić wymagania jakościowe stawiane przez użytkowników oprogramowania komputerowego. W podsumowaniu przedstawiono aktualne kierunki badań i możliwości rozwoju. 2. Modele jakości oprogramowania komputerowego By rozważać kwestie związane z jakością oprogramowania, musimy dysponować punktem odniesienia niezależnym od konkretnego programu komputerowego i narzędzi wykorzystywanych w jego tworzeniu. Taką funkcję pełnią modele jakości oprogramowania. Dotychczas powstało ich wiele, ale najpopularniejsze obecnie są trzy [Kitchenham, Pfleeger i Fenton 1996]: model Dromeya [Dromey 1994, 1998], model McCalla i model ISO-9126 [ISO/IEC 9126-1:2001]. Wśród nich za najbardziej dojrzały uważany jest model Dromeya, ale najbardziej popularny jest model ISO-9126, będący międzynarodowym i powszechnie wykorzystywanym standardem. Modele te wyróżniają od kilkunastu do ponad trzydziestu właściwości (charakterystyk), które można wykorzystać do opisu jakości oprogramowania komputerowego. Model Dromeya ma strukturę hierarchiczną i uwzględnia dwa rodzaje właściwości: właściwości wysokiego poziomu, które mogą być postrzegane zarówno programowania jako jeden ze swoich celów przyjmowała standaryzację procesu tworzenia oprogramowania i uniezależnienie go od indywidualnych cech autora, lecz żadnej z nich nie udało się tego pogodzić z efektywnością prac..

(3) 7. Podstawowe problemy mierzenia jakości.... przez użytkowników, jak i twórców oprogramowania i opisują cały program, oraz właściwości niskiego poziomu, które mogą być postrzegane tylko przez twórców i opisują pojedyncze elementy składowe zwane jednostkami strukturalnymi, z których zbudowany jest program komputerowy2. Relację pomiędzy właściwościami wysokiego i niskiego poziomu przedstawia rys. 1. Jednostki strukturalne, będące efektem hierarchicznej dekompozycji programu komputerowego, odzwierciedlają jego strukturę i są widoczne dla twórców oprogramowania. Dzięki temu mogą oni bezpośrednio wpływać na ich właściwości, czyli na właściwości niskiego poziomu (nazywane również pierwotnymi). Z kolei właściwości niskiego poziomu wpływają w sposób bezpośredni lub pośredni na właściwości wysokiego poziomu, które opisują jakość programu komputerowego jako większej całości zbudowanej z jednostek strukturalnych i są dostrzegane przez użytkowników oprogramowania..

(4) """!

(5) .

(6)

(7) . . "

(8) .

(9) . # .

(10) !.

(11) . Rys. 1. Relacje między właściwościami wysokiego i niskiego poziomu w modelu Dromeya Źródło: opracowanie własne.. Przeanalizujmy poszczególne relacje przedstawione na rys. 1. Najlepiej poznana i udokumentowana teoretycznie i praktycznie jest relacja (1) pomiędzy jednostkami strukturalnymi a programem komputerowym. Opiera się ona na teorii języków programowania i formalnych mechanizmach matematycznych, sprawdzonych praktycznie przy konstruowaniu narzędzi programistycznych takich jak kompilatory i interpretery języków programowania3. Z tego powodu jest ona 2. Rozróżnienie właściwości wysokiego i niskiego poziomu odzwierciedla dualność postaci oprogramowania komputerowego. Program komputerowy istnieje w dwóch podstawowych postaciach: jako kod źródłowy i jako kod wykonywalny. Najbardziej znaną postacią jest kod wykonywalny – w tej postaci program może być instalowany i uruchamiany na komputerach, prawie niemożliwa natomiast jest jakakolwiek jego modyfikacja, gdyż jest on zapisany w języku maszynowym. Kod źródłowy z kolei jest zapisany w językach programowania zrozumiałych dla specjalistów i pozwalających na modyfikowanie oprogramowania, niepozwalających jednak bezpośrednio na uruchomienie programu bez wcześniejszego przekształcenia go na postać kodu wykonywalnego. Kod źródłowy, poza nielicznymi wyjątkami, nie jest udostępniany użytkownikom, a dostęp do niego mają tylko twórcy oprogramowania. 3. Poszczególne języki programowania mają różną składnię i mogą wyróżniać różne rodzaje jednostek strukturalnych. Niemniej jednak liczba jednostek jest na tyle nieduża, że można stworzyć jeden.

(12) 8. Dariusz Dymek. uniwersalna i nie zależy od tego, z jakim modelem jakości oprogramowania mamy do czynienia w konkretnym przypadku. Pozostałe relacje są ściśle zależne od konkretnego modelu jakości, gdyż stanowią jego główną treść. Relacje (2) i (3) przypisują odpowiednim elementom właściwości definiujące ich jakość, natomiast relacja (4) opisuje zależności pomiędzy tymi właściwościami. Podobnie hierarchiczną, choć mniej szczegółową budowę ma model ISO-9126. Jest on nastawiony przede wszystkim na ocenę poziomu jakości oprogramowania z punktu widzenia użytkownika. Model ten wyróżnia trzy poziomy jakości (rys. 2), oddzielając właściwości użytkowe (wymagania użytkownika) od właściwości technicznych (wymagań zewnętrznych i wewnętrznych)..

(13)

(14)

(15) .

(16) .

(17) !

(18) .

(19) .

(20) !

(21) .

(22)

(23) . !

(24)

(25) .

(26) . !

(27) . Rys. 2. Relacja między różnymi poziomami jakości w modelu ISO-9126 Źródło: [ISO/IEC 9126-1 2001].. W modelu określono sześć kategorii właściwości oprogramowania zwanych charakterystykami, wspólnych dla jakości zewnętrznej i wewnętrznej, na które składa się po kilka właściwości określanych jako subcharakterystyki. W zakresie jakości użytkowej model wyróżnia cztery właściwości: wydajność, skuteczność, bezpieczeństwo i zadowolenie. Cechą wyróżniającą ten model spośród pozostałych jest standaryzacja sposobu pomiaru poszczególnych subcharakterystyk [ISO/ IEC 9126-2:2003, ISO/IEC 9126-3:2003, ISO/IEC 9126-4:2001], wprowadzona w najnowszej edycji standardu4. Podstawowy problem nie tkwi jednak jedynie w kwestii pomiaru poszczególnych właściwości, a dotyczy przede wszystkim zależności pomiędzy właściwouniwersalny model, wyróżniający około 20 jednostek strukturalnych. W najprostszym przypadku może on być sumą zbiorów wszystkich jednostek występujących w językach programowania wraz z relacjami pomiędzy nimi opartymi na produkcjach gramatyk definiujących poszczególne języki. 4. Poprzednia edycja standardu ISO-9126 z 1996 r. była mocno krytykowana za brak standaryzacji określania poziomów poszczególnych właściwości. Był to jeden z decydujących powodów stworzenia nowej edycji, która ukazywała się w latach 2001–2003..

(28) Podstawowe problemy mierzenia jakości.... 9. ściami i ich kategoriami oraz możliwości obiektywnej oceny jakości całego produktu. Większość modeli jakości oprogramowania wskazuje jedynie na istnienie zależności pomiędzy właściwościami wysokiego i niskiego poziomu, określając rodzaj tych zależności (stymulanta lub destymulanta), nigdy jednak modele te nie zawierają informacji pozwalających na określenie ilościowych aspektów tych zależności. 3. Mierzenie właściwości oprogramowania Z punktu widzenia inżynierii oprogramowania miary właściwości oprogramowania komputerowego (software metrics) można podzielić na trzy podstawowe kategorie: miary produktu, miary procesu i miary projektu [Kan 2003] mierzące odpowiednio właściwości produktu (oprogramowania), procesu jego powstawania i charakterystykę projektu. Miary jakości stanowią podzbiór tych trzech kategorii. Są one ściślej związane z miarami produktu i procesu, aczkolwiek właściwości projektu, takie jak np. wielkość i doświadczenie zespołu projektowego, wpływają w istotny sposób na jakość oprogramowania. Same miary jakości możemy z kolei podzielić na dwie kategorie: miary jakości ostatecznego produktu (end-product quality metrics) oraz wewnątrzprocesowe miary jakości (in-process quality metrics). Podstawowym zadaniem inżynierii oprogramowania jest znalezienie relacji pomiędzy miarami jakości produktu końcowego, wewnątrzprocesowymi miarami jakości i charakterystyką (miarami) projektu oraz wykorzystanie uzyskanych rezultatów do poprawy jakości produktu i procesu jego tworzenia. Problem konstrukcji miar, w szczególności miar produktu, jest silnie uwarunkowany przez wspomniany wcześniej unikalny i abstrakcyjny charakter oprogramowania komputerowego. Ta specyfika skutkuje brakiem pojedynczych, powszechnie uznanych i używanych miar nawet w zakresie podstawowych właściwości oprogramowania. Sytuację w tym zakresie najlepiej obrazuje problem związany z mierzeniem wielkości oprogramowania. Istnieje kilka różnych powszechnie wykorzystywanych miar wielkości programu, z których dwie: liczba linii kodu (LOC – line of code) i liczba punktów funkcyjnych (FP – function points) są najpopularniejsze. Struktura kodu źródłowego zależy od wielu czynników, m.in. od języka programowania5, standardów kodowania i przyzwyczajeń twórców. W konsekwencji bez znajomości wszystkich tych czynników nie można zapewnić porównywalności miary bazującej na liczbie linii kodu. Ponadto nie ma zgody w kwestii tego, co traktować jako pojedynczą linię kodu: 5. Wielkość dwóch dokładnie tak samo działających programów napisanych w różnych językach programowania może się różnić nawet o kilka rzędów wielkości. Wynika to z faktu, że jednej linii kodu w języku czwartej generacji może odpowiadać nawet kilkaset lub ponad tysiąc linii kodu w języku trzeciej generacji i proporcja ta nie jest stała – może się wahać w bardzo szerokim zakresie..

(29) 10. Dariusz Dymek. – linie kodu wykonywalnego, – linie kodu wykonywalnego i deklaracji danych, – linie kodu wykonywalnego, deklaracji danych i komentarzy, – wszystkie linie wyświetlane na ekranie. Każda z nich w przypadku konkretnego programu daje inne wyniki. Oznacza to, że bez znajomości wszystkich tych szczegółowych danych nie możemy porównywać wielkości programów wyrażonych w LOC. Dodatkową bardzo istotną wadą tej miary jest fakt, że jeżeli nawet przyjmiemy, iż oddaje ona w przybliżeniu wielkość programu, niewiele mówi o jego stronie funkcjonalnej – w konsekwencji nie można jej bezpośrednio wykorzystywać do porównywania dwóch programów, nawet napisanych w tym samym języku programowania [Briand, Morasca i Basili 1996]. Zaletą tej miary jest jej prostota oraz możliwość lokalnego wykorzystania w procesach planowania zasobów (wydajność programisty jest mierzona w liczbie linii kodu na dzień pracy). Druga ze wspomnianych miar określa wielkość programu na podstawie liczby funkcji realizowanych przez program [Szyjewski 1994]. Na podstawie analizy istniejących programów stworzono model funkcjonalny programu komputerowego, a następnie przypisano poszczególnym funkcjom wartości liczbowe zwane punktami funkcyjnymi, odzwierciedlające nakład pracy potrzebny do ich realizacji. Na podstawie analizy zrealizowanych programów oszacowano średnią liczbę linii kodu odpowiadającą jednemu punktowi funkcyjnemu dla danego języka programowania. Dzięki temu możliwe stało się przeliczanie punktów funkcyjnych na liczbę linii kodu, ale ponieważ odbywa się to na podstawie wartości uśrednionych, wyniki szacunkowe mogą się różnić nawet o rząd wielkości od rzeczywistych. Drugi istotny problem tkwi w założeniach miary opartej na punktach funkcyjnych. Założenie o istnieniu wspólnego modelu funkcyjnego dla oprogramowania komputerowego powoduje, że ta metoda pomiaru wielkości programu komputerowego jest skuteczniejsza w przypadku programów typowych, a całkowicie zawodzi w przypadku rozwiązań niestandardowych i nowatorskich, które stanowią znaczną część tworzonego oprogramowania. Z tego powodu nie można jej traktować jako miary uniwersalnej. Przedstawiony problem miary wielkości programu jest ściśle związany z problemem pomiaru jakości programu. Jedną z podstawowych miar wykorzystywanych w zakresie jakości jest gęstość błędów, czyli liczba błędów na jednostkę wielkości [ISO/IEC 9126-1:2001]. Brak powszechnie uznanej i obiektywnej miary wielkości powoduje, że uzyskiwane rezultaty nie są porównywalne między różnymi projektami. Nie uniemożliwia to wykorzystywania tych miar w pojedynczych projektach, ale nie pozwala na zbudowanie uniwersalnego wzorca w zakresie jakości, określającego np. standardowy poziom dopuszczalnej gęstości błędów dla różnych poziomów jakości. Miara wielkości programu nie jest jedynym takim.

(30) Podstawowe problemy mierzenia jakości.... 11. problemem. Z analogiczną sytuacją mamy do czynienia w przypadku innych podstawowych właściwości oprogramowania6. Konsekwencją tej sytuacji jest brak uniwersalnych i jednoznacznych standardów w zakresie pomiaru właściwości oprogramowania jako produktu, w szczególności miar jakości oprogramowania. Istniejące standardy, takie jak wspomniany ISO-9126, zawierają jednak propozycje miar jakości wraz z zasadami ich stosowania, które umożliwiają stworzenie efektywnego systemu mierzenia jakości oprogramowania w ramach pojedynczego projektu lub organizacji. Zasady te pozwalają na lokalne uniknięcie skutków braku jednoznaczności miar, wymuszając ich doprecyzowanie na poziomie organizacji. Uzyskanych wyników nie wolno jednak traktować jako porównywalnych dla różnych organizacji, gdyż wdrożone zgodnie ze standardem metody pomiaru mogą być odmienne. W tym kontekście kompletna definicja miary powinna zawierać: – precyzyjną, formalną definicję miary, w tym dokładną informację, jakie właściwości są mierzone, – dokładny opis procesu pomiaru, w tym opis danych potrzebnych do wyliczenia wartości, wraz z określeniem sposobu ich zbierania, przesyłania, gromadzenia i przetwarzania, – określenie częstości dokonywania pomiarów, w tym minimalną liczbę pomiarów oraz minimalne i maksymalne odległości czasowe pomiędzy kolejnymi pomiarami, – zasady analizy i prezentacji danych i wyników, – sposoby interpretacji danych i wyników, w tym przedziały wartości pożądanych i wartości dopuszczalnych oraz sposoby wpływania na wartość miary, – zasady porównawcze, a w szczególności informacje na temat możliwych korelacji z innymi wykorzystywanymi miarami tej samej lub innych właściwości. Dopiero przy zachowaniu tych wymagań możliwe jest praktyczne wykorzystanie miar oprogramowania. Należy zwrócić szczególną uwagę na określenie procesu i częstości dokonywania pomiaru. Te wymagania są bardzo istotne z dwóch powodów: dokładny opis procesu dokonywania pomiaru pozwala na oszacowanie kosztów takiego procesu, natomiast określenie częstości pomiaru pozwala oszacować ich liczbę. Tym samym jesteśmy w stanie oszacować podstawowe koszty wykorzystania miary. Znajomość procesu jest w tym wypadku konieczna, ponie6. Przykłady takich sytuacji można znaleźć w [Briand, Morasca i Basili 1996, Morasca i in. 1997, Poels i Dedene 1997, Zuse 1997, Hitz, Montazeri 1996, Briand, Emam i Morasca 1995a, 1995b]. Tam też autorzy proponują formalne kryteria weryfikacji miar dla kilku podstawowych właściwości oprogramowania takich jak wielkość, złożoność czy spójność. Nie wskazują oni konkretnych miar dla tych właściwości, lecz próbują, na podstawie teoretycznych rozważań w zakresie inżynierii oprogramowania i teorii pomiaru, wskazać minimalny zestaw kryteriów, które te miary musiałyby spełniać..

(31) 12. Dariusz Dymek. waż w przypadku oprogramowania mamy niewielkie możliwości automatyzacji pomiaru, a w większości przypadków przy mierzeniu właściwości konieczne jest zaburzenie normalnego funkcjonowania procesu tworzenia oprogramowania. Z tego powodu proces pomiaru nie może mieć charakteru ciągłego ani być przeprowadzany zbyt często. Istniejący poziom niejednoznaczności w zakresie definiowania i pomiaru podstawowych właściwości oprogramowania przenosi się częściowo na poziom miar procesu tworzenia oprogramowania, a dokładniej wszędzie tam, gdzie pośrednio wykorzystywane są miary produktu, jak w przypadku wydajności czy postępu prac. Znajduje ona również odbicie w obszarze planowania projektów w zakresie takich podstawowych wartości jak czas i koszt, będących w znacznej mierze pochodną pracochłonności. Specyficzne cechy oprogramowania komputerowego, w połączeniu z problemem w zakresie precyzyjnego określenia podstawowych jego właściwości, powodują wyjątkowo niską skuteczność w zakresie planowania7. Metody wypracowane w innych dziedzinach mogą być wykorzystane tylko w ograniczonym zakresie. Dlatego w ramach inżynierii oprogramowania opracowano nowe lub zaadaptowano wcześniej istniejące metody szacowania i planowania kosztów i zasobów [Kramerer 1987, Dymek 2000, Irdi, Abran i Khoshgoftaar 2002, Mockus, Weiss i Zhang 2003, Antoniol i in. 2004]. Obecnie funkcjonuje kilkanaście metod, jednak zakres skutecznego ich wykorzystania jest ograniczony przeważnie do projektów typowych. Świadomość takiej sytuacji sprawia, że wiele organizacji, stając przed problemem tworzenia własnego systemu zapewnienia jakości, dla którego mechanizmy mierzenia właściwości oprogramowania w zakresie produktu, procesu i projektu są jednym z podstawowych składników, zdecydowało się zbudować własne rozwiązania. Mimo związanego z takim podejściem ryzyka oraz konieczności poniesienia znacznych nakładów pozwala ono uniknąć powielenia cudzych błędów i daje możliwość wyboru lub konstrukcji miar dostosowanych do standardów organizacyjnych i wykorzystywanych narzędzi programistycznych, w tym języków programowania. Z drugiej strony takie podejście sprawia, że rośnie liczba miar stosowanych przez różne organizacje, a tym samym maleją szanse na przyjęcie powszechnie uznanych standardów w zakresie pomiaru właściwości oprogramowania komputerowego. Pełniący obecnie funkcję punktu odniesienia w tym zakresie standard ISO-9126 rzadko jest wykorzystywany bezpośrednio – stanowi on bazę wykorzystywaną do budowy własnych rozwiązań lub ich weryfikacji [Cote i in. 2004].. 7. Według danych The Gardner Group jedynie ok. 20% projektów informatycznych kończy się pełnym sukcesem..

(32) Podstawowe problemy mierzenia jakości.... 13. 4. Praktyczne wykorzystanie oprogramowania – zestawy miar Chcąc zastosować miary właściwości oprogramowania w praktyce, stajemy przed jeszcze jednym problemem. Oprogramowanie komputerowe jest produktem złożonym, w skład którego oprócz samego programu komputerowego w różnych postaciach (kod źródłowy, kod wykonywalny) wchodzą jeszcze inne składniki, jak dokumentacja końcowa (m.in. użytkownika, instalacyjna, administratora), dokumentacja projektowa (specyfikacja, analiza, projekt). Ponadto jego tworzenie jest procesem złożonym, składającym się z wielu faz, których relacje w zależności od przyjętego modelu cyklu życia oprogramowania (kaskadowy, przyrostowy, ewolucyjny, spiralny itd.) mogą ulegać zmianom. Wiąże się to z potrzebą mierzenia dużej liczby własności oprogramowania w zakresie produktu i procesu. Proces pomiaru stanowi źródło zakłóceń w procesie tworzenia oprogramowania. Oznacza to, że wraz ze wzrostem liczby miar wzrasta koszt procesu pomiaru. W konsekwencji, budując system zapewnienia jakości, musimy uwzględnić ten problem i pogodzić ze sobą często przeciwstawne wymagania: – duża liczba właściwości w naturalny sposób sugeruje dużą liczbę miar potrzebnych do kontroli ich poziomu, – wpływ procesu pomiaru na sam proces tworzenia programu komputerowego oraz jego koszt sprawia, że pożądane jest maksymalne zmniejszenie liczby miar, – najbardziej przydatne są miary produktu, które można wykorzystać nie tylko do samego programu komputerowego, ale również do mierzenia jakości innych produktów wchodzących w skład oprogramowania, – w doborze miar procesu powinno się brać pod uwagę wykorzystanie ich w jak największej liczbie faz, co pozwoli zmniejszyć liczbę miar, jednocześnie zapewniając ciągłość (w sensie porównywalności) procesu pomiaru. W praktyce znalazło to swoje odbicie w konstrukcji zestawów miar właściwości oprogramowania (software measurement framework). Podczas konstrukcji takiego zestawu miar musimy uwzględnić wspomniane wymagania oraz oczekiwania osób zaangażowanych w proces tworzenia oprogramowania. W zależności od roli w zespole projektowym potrzebują one narzędzi mierzących właściwości produktu, procesu lub projektu, które dostarczą im obiektywnych informacji na temat bieżącego stanu i istniejących trendów, informacji koniecznej do skutecznego zarządzania. W konsekwencji wykorzystywane w praktyce zestawy miar oprogramowania są bardzo zróżnicowane i podporządkowane potrzebom konkretnych organizacji8. 8. Szczególnie dobrze, ze względu na jawność wielu działań, sytuacja ta jest widoczna w Stanach Zjednoczonych, które pozostają od kilkudziesięciu lat niekwestionowanym liderem w wykorzystaniu technologii informatycznej. W wielu instytucjach federalnych takich jak Departament Obrony.

(33) 14. Dariusz Dymek. Liczba miar wchodzących w skład zestawu waha się od kilkunastu do kilkudziesięciu. Przykładowo w standardzie wewnętrznym armii USA istnieje 14 miar właściwości oprogramowania [DA Pam 73-1 Test... 2003], a w standardzie JLC (Joint Logistic Commanders) Departamentu Obrony USA jest ich 39 [Practical Software Measurement... 1996]. Warto zwrócić uwagę na liczbę miar produktu związanych z jakością oprogramowania. W pierwszym ze wspomnianych przykładów jest ich 6, a w drugim 14 – pozostałe są miarami związanymi z jakością procesu lub charakterystyką projektu. Oznacza to, że liczba miar związanych z jakością produktu jest znacznie mniejsza od liczby właściwości związanych z jakością oprogramowania, praktycznie w każdym z modeli jakości. Nie oznacza to rezygnacji z pomiaru większości właściwości. Zamiast pojedynczych miar poszczególnych właściwości wykorzystywane są miary, których wartość zależy od kilku właściwości. Tym samym wartości tych miar dają nam syntetyczny obraz jakości produktu, przy zachowaniu wymogu minimalizacji liczby miar. Tworzenie oprogramowania komputerowego ma charakter projektowy. Przekłada się to również na mierzenie właściwości oprogramowania. Każdy projekt informatyczny stanowi odrębne środowisko organizacyjne znajdujące się na styku organizacji klienta (przyszłego użytkownika) i wykonawcy (twórcy oprogramowania). We współczesnym pojmowaniu jakości, gdy oprócz jakości technicznej produktu bardzo ważne jest zaspokojenie potrzeb i oczekiwań klienta, każdy z projektów charakteryzuje się pewną różnorodnością celów, które powinny zostać zrealizowane. Cele te powinny znaleźć swoje odzwierciedlenie w wykorzystywanym zestawie miar właściwości oprogramowania, stąd konieczność dostosowania standardowego zestawu miar do potrzeb konkretnego projektu (ang. customization). Zmiany te jednak nie powinny być zbyt duże, w szczególności w zakresie redukcji wykorzystywanych miar9, i muszą być przeprowadzone zgodnie z obowiązującymi w tym zakresie standardami organizacyjnymi. W konstrukcji takich dopasowanych do potrzeb konkretnego projektu zestawów miar wykorzystywane są różne metody, od standardowych metod związanych ze sterowaniem jakością, jak zaproponowana przez Shewharta i Deminga w 1986 r. metoda PDCA (plan-do-check-act, czyli planuj-wykonaj-sprawdź-działaj) [McAndrews 1993], po metody specyficzne dla inżynierii oprogramowania. Wśród tych ostatnich za najbardziej dojrzałą uważana jest zaproponowana w 1994 r. przez V.R. Basilego metoda GQM (goal-question-metric, czyli cel-pytanie-miara). Od czy NASA różne jednostki korzystają z własnych zestawów miar dostosowanych do ich potrzeb [Practical Software Measurement... 1996, DA Pam 73-1 Test... 2003, Wallance, Ippolito i Cuthill 1996, Software Measurement Guidebook 1995, Guidelines for Successful... 2000]. 9. Generalnie przyjmuje się zasadę, że rozbudowuje się standardowy zestaw miar o nowe, dostosowane do potrzeb konkretnego projektu, nie usuwając żadnej ze standardowych miar. Dzięki temu zyskujemy porównywalność danych z różnych projektów i możliwości ich dalszej analizy..

(34) Podstawowe problemy mierzenia jakości.... 15. tego czasu była ona systematycznie rozwijana [Basili, Caldiera i Rombach 1995, Grey i MacDonell 1997b, Briand, Morasca i Basili 2002] i jest uważana za jedną z podstawowych metod w tym zakresie10. Opiera się ona systematycznym podejściu do tematu poprzez określenie celu (goal) działania możliwego do wyrażenia w postaci pytania (question), na które z kolei można odpowiedzieć w sposób kwantyfikowalny, korzystając z miary (metric) konkretnych właściwości oprogramowania. Wybór celu jest dokonywany w terminologii konkretnej potrzeby (rozwinąć, przewidzieć, sklasyfikować) z konkretnej perspektywy (kierownik, klient, użytkownik, twórca), dla danego obiektu (specyfikacja, dokumentacja, program), w zadanym środowisku (metoda, ludzie, narzędzia). Podejście do problemu od strony potrzeb (czyli celów działania) zamiast od strony możliwości (co możemy zmierzyć) ukierunkowuje cały proces na praktyczne jego wykorzystanie. Ułatwia to zrozumienie zależności pomiędzy celami i miarami, a tym samym czyni cały proces pomiaru bardziej zrozumiałym dla wszystkich jego uczestników. W ramach doskonalenia pierwotnie zaproponowanej metody postulowano wprowadzenie nowych elementów w hierarchii, takich jak cele nadrzędne, cele podrzędne, dziedziny i poddziedziny, pytania nadrzędne, pytania podrzędne, ogólne charakterystyki miar oraz ich uzależnienie od wykorzystywanych konkretnych narzędzi programistycznych. Taka rozbudowa hierarchii pozwala na dokładniejszą identyfikację obszaru zastosowania miary i pozwala wybierać miary bardziej uniwersalne, które na podstawie tych samych danych pozwolą odpowiedzieć na większą liczbę pytań. Metoda GQM jest narzędziem, które swoim zakresem obejmuje nie tylko techniczne aspekty zapewnienia jakości, ale może być również wykorzystywane do rozwiązywania problemów związanych z zarządzaniem projektem informatycznym. Działa ona jak pętla zwrotna, gdyż poprzez związanie kosztów ze stawianymi celami dostarcza informacji pozwalającej na weryfikację pierwotnie przyjętych celów, a w niektórych przypadkach może powodować ich zmianę lub całkowite zaniechanie działań w danym obszarze jako potencjalnie nieopłacalnych. Systematyczne i konsekwentne stosowanie zestawów miar właściwości oprogramowania jest uważane za wyznacznik dojrzałości organizacji zajmujących się tworzeniem oprogramowania. Znajduje to swoje odbicie w takich standardach jak CMMI, gdzie wdrożenie mechanizmów pomiaru właściwości produktu i procesu jest traktowane jako warunek osiągnięcia wyższych poziomów doskonałości (poziom 4 w 6-stopniowej skali) [CMMI for Development... 2006].. 10. Praktyczne przykłady wykorzystania metody GQM można znaleźć w [Birk, Sollingen i Jarvinen 1998, Clement, McGregor i Cohen 2005, Goethert i Hayes 2001, Goethert i Siviy 2004]..

(35) 16. Dariusz Dymek. 5. Podsumowanie Problemy mierzenia jakości oprogramowania komputerowego w inżynierii oprogramowania są pochodną problemów definiowania i mierzenia właściwości oprogramowania komputerowego jako produktu i właściwości procesu jego wytwarzania. Znaczenie oprogramowania komputerowego w funkcjonowaniu dzisiejszego społeczeństwa sprawiło, że potrzeby w zakresie rozwiązywania tych problemów zostały dostrzeżone zarówno przez teoretyków, jak i praktyków. Jakość oprogramowania komputerowego nie jest już dzisiaj problemem jedynie wąskiej grupy specjalistów z dziedziny inżynierii oprogramowania. Powszechność wykorzystywania oprogramowania komputerowego, jego znaczenie w życiu codziennym ludzi i funkcjonowaniu różnych organizacji, wielkość środków finansowych przeznaczanych na budowę coraz nowszych, bardziej zaawansowanych systemów sprawiają, że bezpośrednio lub pośrednio kwestia jakości oprogramowania dotyczy nas wszystkich. Nie można skutecznie sterować jakością oprogramowania bez obiektywnej informacji, której jedynym źródłem są miary właściwości oprogramowania w zakresie właściwości produktu i procesu jego wytwarzania. Podstawowe problemy związane z mierzeniem jakości oprogramowania można sprowadzić do trzech głównych zagadnień, a mianowicie: – dalszej standaryzacji i rozbudowy modeli jakości oprogramowania, w tym formalnych definicji podstawowych właściwości, – konstrukcji efektywnych miar właściwości oprogramowania dostosowanych do różnych narzędzi programistycznych i dziedzin ich wykorzystania, – upowszechnienia metod konstruowania zestawów miar dostosowanych do potrzeb i możliwości organizacji z nich korzystających. Niebagatelną rolę w zakresie rozwiązywania tych problemów mogą odegrać ośrodki kształcące specjalistów w zakresie technologii informatycznych i przyszłych użytkowników (klientów). Powszechna świadomość istniejących uwarunkowań, połączona z naciskiem na wykorzystywanie już istniejących, sprawdzonych metod w zakresie sterowania jakością może nie tylko przyczynić się do upowszechnienia tych metod, ale również być impulsem do ich dalszego doskonalenia lub stworzenia nowych. Literatura Antoniol G. i in. [2004], Assessing Staffing Needs for a Software Maintenance Project through Queuing Simulation, IEEE Transactions on Software Engineering, nr 30(1). Basili V.R., Caldiera G., Rombach H.D. [1995], The Goal Question Metric Approach, Institute for Advanced Computer Studies, Department of Computer Science, University of Maryland. Birk A., Solingen R., Jarvinen J. [1998], Business Impact, Benefit, and Cost of Applying GQM in Industry: An In-depth, Long-term Investigation at Schlumberger RPS,.

(36) Podstawowe problemy mierzenia jakości.... 17. 5th International Symphosium on Software Metrics, Bethesda, Maryland, November 19–21. Briand L., Emam K.E., Morasca S. [1995a], On the Application of Measurement Theory in Software Engineering, International Software Engineering Research Network, ISERN-95-04. Briand L., Emam K.E., Morasca S. [1995b], Theoretical and Empirical Validation of Software Product Measures, International Software Engineering Research Network, ISERN-95-03. Briand L., Morasca S., Basili V.R. [1996], Property-based Software Engineering Measurement, Technical Report CS-TR-3368-1, University of Maryland, IEEE Transactions on Software Engineering, vol. 22, nr 1. Briand L., Morasca S., Basili V.R. [2002], An Operational Process for Goal-driven Definition of Measure, IEEE Transactions on Software Engineering, vol. 28, nr 12. Clements P.C., McGregor J.D., Cohen A.G. [2005], The Structure Intuitive Model for Product Line Economics, Technical Report, CMU/SEI-2005-TR-003. CMMI for Development [2006], version 1.2, Technical Report CMU/SEI-2006-TR-008. Cote M.A. i in. [2004], Evolving a Corporate Software Quality Assessment Exercise: A Migration Path to ISO/IEC 9126, „Software Quality Process”, vol. 6, nr 3. DA Pam 73-1 Test and Evaluation if Support of Systems Acquisition [2003], US Department of Defence, May. Dromey R.G. [1994], A Model for Software Product Quality, Australian Software Quality Research Institute, October, http://www-sqi.cit.gu.edu.au. Dromey R.G. [1998], Software Product Quality: Theory, Model and Practice, Australian Software Quality Research Institute, March. Dymek D. [1999], Metody estymacji kosztów w inżynierii oprogramowania, Strategia systemów informacyjnych, Rytro, 22–24 września. Dymek D. [2000], Wybrane metody analizy danych w modelach predykcyjnych, Zeszyty Naukowe Akademii Ekonomicznej w Krakowie, Kraków. Grey A.R., MacDonell S.G. [1997a], A Comparison of Techniques for Developing Predictive Models of Software Metrics, „Information and Software Technology”, nr 39. Grey A.R., MacDonell S.G. [1997b], GQM++ A Full Life Time Cycle Framework for the Development and Implementation of Software Metric Program, Proceedings of ACOSM’97 4th Australian Conference on Software Metrics, Canberra, ASMA. Goethert W., Hayes W. [2001], Experience in Implementing Measurement Programs, Technical Note CMU/SEI-2001-TN-026. Goethert W., Siviy J. [2004], Applications of the Indicator Temple for Measurement and Analysis, Technical Note CMU/SEI-2004-TN-024. Guidelines for Successful Acquisition and Management of Software-intensive Systems, Version 3 [2000], Department of the Air Force, Software Technology Support Center. Hitz M., Montazeri B. [1996], Chidamber and Kemerer’s Metric Suite: A Measurement Theory Perspective, IEEE Transactions on Software Engineering, vol. 22, nr 4. Irdi A., Abran A. Khoshgoftaar T.M. [2002], Estimating Software Project Effort by Analogy Based on Linguistic Value, Proceedings of 8th IEEE Symposium on Software Metric, Ottawa. ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality – Part 1: Quality Model, International Organization for Standardization..

(37) 18. Dariusz Dymek. ISO/IEC 9126-4:2001, Software Engineering – Software Product Quality – Part 4: Quality in Use Metrics, International Organization for Standardization. ISO/IEC 9126-2:2003, Software Engineering – Software Product Quality – Part 2: External Metrics, International Organization for Standardization. ISO/IEC 9126-3:2003, Software Engineering – Software Product Quality – Part 1: Internal Metrics, International Organization for Standardization. Kan S.H. [2003], Metrics and Models in Software Quality Engineering – 2nd Edition, Addison Wesley Professional. Kitchenham B., Pfleeger S.L., Fenton N. [1995], Towards a Framework for Software Measurement Validation, IEEE Transactions on Software Engineering, vol. 21, nr 12. Kramerer C.F. [1987], An Empirical Validation of Software Cost Estimation Models, Communications of the ACM, vol. 30. Krawczyk H. [1999], Narzędzia i eksperymenty pomiarowe oprogramowania, Jedenasta Górska Szkoła PTI Szczyrk ’99, 21–25 czerwca. McAndrews D.R. [1993], Establishing a Software Measurement Process, Raport CMU/ SEI-93-TR-16, Software Engineering Institute, Carnegie Mellon University, July. Mockus A., Weiss D., Zhang P. [2003], Understanding and Predicting Effort in Software Projects [w:] Proceedings of the 25th International Conference on Software Engineering, ICSE. Morasca S. i in. [1997], Comments on „Toward a Framework for Software Measurement Validation”, IEEE Transactions on Software Engineering, vol. 23, nr 3. Poels G., Dedene G. [1997], Comments on „Property-based Software Engineering Measurement”, IEEE Transactions on Software Engineering, vol. 23, nr 3. Practical Software Measurement – A Guide to Objective Program Insight [1996], Joint Logistic Commanders, Joint Group on System Engineering, US Department of Defence, version 2.1. Software Measurement Guidebook [1995], Software Engineering Laboratory Series SEL-94-102, NASA, June. Szyjewski Z. [1994], Komputerowe wspomaganie tworzenia systemów informatycznych, Szczecin. Turski W.M. [1978], Metodologia programowania, WNT, Warszawa. Wallance D.R., Ippolito L.M., Cuthill B. [1996], NIST Special Publication 500-234 Reference Information for Software Verification and Validation Process, US Department of Commerce, Technology Administration, NIST, Computer Systems Laboratory, March. Zuse H. [1997], Replay to „Property-based Software Engineering Measurement”, IEEE Transactions on Software Engineering, vol. 23, nr 8. Fundamental Problems of Quality Measurement in Software Engineering The issue of computer software quality and its measurement is rather underestimated by software designers. Nevertheless, growing users demands and increasing role of software in everyday life cause that this problem becomes more and more significant. The study outlines a current state in the domain of software quality and presents basic problems concerning software quality measurement. Key words: software quality models, software quality measurement..

(38)