PRZEGLĄD MIAR OCENY OPROGRAMOWANIA. Paweł WEICHBROTH, Cezary ORŁOWSKI

Transkrypt

1 PRZEGLĄD MIAR OCENY OPROGRAMOWANIA Paweł WEICHBROTH, Cezary ORŁOWSKI 1. Wstęp Problem oceny oprogramowania istnieje od momentu pojawienia się pierwszego programu komputerowego. Historycznie miary jakości oprogramowania miały zupełnie inne przeznaczenie, gdyż skupiały się na częstotliwości defektów lub błędów oprogramowania. Błędnie bazowało to na założeniu, że jakość oprogramowania to brak błędów. Stąd też używano prostej statystyki typu liczby błędów, wykrytych w określonym przedziale czasu (np. rocznym) lub w danej wersji programu, na tysiąc wierzy kodu tzw. gęstości błędów. Oczywiste jest, iż niższe wartości tej miary oznaczały wyższą jakość programu. Jedną z pierwszych znanych miar wykorzystanych do opisu programów komputerowych był jego rozmiar [17]. Możemy stwierdzić, iż rozmiar oprogramowania (ang. software size) jest miarą objętości, długości, ilości, znaczenia i ogólnie rozmiaru programu komputerowego [5]. W połowie lat 60-tych pierwszą stosowaną miarą rozmiaru oprogramowania była liczba linii kodu LOC (ang. lines of code). Prawie dekadę później, w późnych latach 70-tych, pojawiły się bardziej wyszukane miary rozmiaru oprogramowania takie jak: liczba tokenów (ang. number of tokens), wolumin (ang. volume), liczba funkcji (ang. function count), liczba punktów funkcyjnych (ang. function points) [5]. Kolejną miarą opisującą rozmiar programu był wolumin, oparty na wielkości linii kodu w bitach, reprezentowany przez zera i jedynki [10]. Krótko potem, pojawiła się liczba funkcji, jako miara rozmiaru oprogramowania, określająca stopień modularności programu [2]. Po niej, zaproponowano liczbę punktów funkcyjnych, której ideą było oszacowanie liczby, wejść, wyjść, plików głównych, zapytań i interfejsów [1]. Jednakże rozmiar oprogramowania nie jest miarą jakości oprogramowania samą w sobie, stanowi fundament wielu miar w dzisiejszych czasach (np. liczby defektów, błędów, stosunku błędów do linii kodu, punktów funkcyjnych). Ponadto, często spotyka się opinie, iż rozmiar oprogramowania stanowi podstawową miarę oceny złożoności oprogramowania [14]. Z powyższych względów, ewolucja pomiaru jakości oprogramowania byłaby niekompletna bez wprowadzenia na temat rozmiaru oprogramowania. 2. Błędy oprogramowania W latach 50-tych XX wieku, pierwszą stosowaną miarą oceny jakości oprogramowania była liczba wykrytych błędów. Można je rozumieć jako wadliwe działania ludzkie w procesie implementacji programu. Koncepcja błędów na wyrażenie (ang. errors per statement") po raz pierwszy pojawiła się we wczesnych latach 60-tych, a jej dorobkiem jest pojęcie wystąpienia błędu (ang. error proneness). Pojęcie gęstości błędu (ang. error density) powstało w połowie lat 70-tych i odnosiło się do prostego stosunku błędów do wielkości oprogramowania [24]. Gęstość błędu była stosowana w odniesieniu do liczby anomalii powodujących błędy do wielkości oprogramowania [15]. Termin gęstości wad (ang. defect density), używany w połowie lat 80-tych, był stosunkiem liczby błędów programowych do wielkości oprogramowania [23]. Wiele różnych cech było branych pod uwagę takich jakich liczba wymagań, projekt, kodowanie, czy testowanie [5]. Na początku lat 90-tych pojawiła się koncepcja gęstości problemu (ang. problem density), która odnosiła się do liczby problemów

2 zgłoszonych przez klientów [14]. Praktyka liczenia błędów i wad, jako środka mierzenia jakości oprogramowania cieszyły się nieprzerwaną popularnością przez ponad pięć dekad. 3. Atrybuty oprogramowania Innym podejściem do problemu mierzenia jakości oprogramowania była praktyka określania ilości i złożoności jego atrybutów. Atrybuty oprogramowania są przyporządkowaną jakościową cechą, taką jak funkcjonalność, wydajność i użyteczność. Logicon zaprojektował model do mierzenia atrybutów oprogramowania takich jak poprawność, logiczność, sprawność, stopień optymalizacji, zrozumiałość, modyfikowalność i użyteczność [22]. Następnie, zostały zidentyfikowane atrybuty oprogramowania takie jak: przenośność, wiarygodność, efektywność, modyfikowalność, testowalność, ergonomia i zrozumiałość [3]. Wymienione prace przyczyniły się do powstania wielu modeli do mierzenia atrybutów konserwacji oprogramowania [25] i nawet projektowania bazy danych [8]. Podejście skierowane na klienta doprowadziło do wypracowania jakościowych i ilościowych metryk oprogramowania [4,6,7]. W dalszej kolejności, został wypracowany model FURPS, na który składało się pięć atrybutów: funkcjonalność (ang. functionality), użyteczność (ang. usability), wiarygodność (ang. reliability), wydajność (ang. performance) i stopień wsparcia (ang. supportability) [9]. 4. Statyczne modele błędów Jednym z najwcześniejszych podejść do przewidywania jakości oprogramowania były modele statyczne, które opierały się teorii niezawodności. Model statyczny posługuje się innymi atrybutami do oszacowania liczby błędów w oprogramowaniu - nie bierze pod uwagę współczynnika zmian [5]. Jednym z pierwszych modeli predykcji błędów były funkcja wielkości, rachunek decyzji (decision count) i liczba wywołań procedur. Zostały stworzone linowe modele do 10 wejść dla różnych typów wyrażeń w kodzie źródłowym takich jak: komentarze, dane czy instrukcje [18]. W teorii nauki o programowaniu wolumin jest wejściem w modelu i tym samym funkcją języka programu [10]. Równolegle w tym samym czasie, McCabe przedstawił topologiczną, bazującą na teorii grafów miarę złożoności cyklomatycznej, jako miarę liczby liniowo niezależnych ścieżek, które składają się na program komputerowy. Zostało rozwiniętych jeszcze wiele innych skrzyżowanych ze sobą modeli, biorących pod uwagę zasoby słów (ang. vocabulary), długość (ang. length), złożoność (ang. difficulty) i prachochłonność (ang. effort) [23]. Później firma IBM rozwinęła modele szacowania błędów i wystąpień defektów w oprogramowaniu, które zostały wykorzystane do projektowania systemów operacyjnych [14]. 5. Złożoność oprogramowania Systemy komputerowe są tworami o wysokim stopniu złożoności. Na początku lat 70-tych, badania na temat złożoności oprogramowania stały się jedną z bardziej powszechnych metod oceny jakości programów komputerowych. Złożoność oprogramowania może być rozumiana jako stopień kompozycji i dekompozycji, czyli podział na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji. Powstało wiele technik obliczania lub raczej szacowania stopnia złożoności. Najprostsza z nich to LOC (ang. lines of code) lub SLOC (ang. source lines of code). Jest to syntetyczna miara dające ogólne pojęcie o skali programu, jednak nie jest wystarczająca do szczegółowych analiz. Wartość LOC jest silnie zależna od poziomu wykorzystanego języka programowania ten sam algorytm w

3 języku wysokiego poziomu będzie miał wielokrotnie mniej linii kodu niż w języku niskiego poziomu. W roku 1977 profesor Maurice H. Halstead zaproponował takie miary jak [12]: liczba różnych operatorów w programie (n 1 ) liczba różnych operandów w programie (n 2 ) liczba wystąpień operatora (N 1 ) liczba wystąpień operandu (N 2 ) opisu: gdzie: W kolejnym etapie wyprowadził zestaw miar pochodnych od podstawowych w celu słownika symboli (ang. Vocabulary) (n), n=n 1 +n 2 (1) długości programu (ang. Length) (N), N=N 1 +N 2 =n 1 log 2 (n 1 )+n 2 log 2 (n 2 ) (2) rozmiar (ang. Volume) (V), V=Nlog 2 (n)=nlog 2 (n 1 +n 2 ) (3) poziom (ang. Level) (L), L=V*/V=(2/n 1 )*(n 2 /N 2 ) (4) trudność (ang. Difficulty) (D), D=V/V*=(n 1 /2)*(N 2 /n 2 ) (5) pracochłonność (ang. Effort) (E), E=V/L (6) błędy (ang. Faults) (B), B=V/S* (7) V* to minimalny rozmiar reprezentowany przez wbudowaną funkcję, która może wykonywać zadanie całego programu, S* to średnia liczba umysłowych decyzji lub rozróżnień między błędami, oszacowana przez Halsteada na 3000 [12]. Wadą tego podejścia jest, iż długość programu zależy od dwóch zmiennych N 1 i N 2, których wartość jest dokładnie znana tuż przed zakończeniem pisania programu. 6. Wiarygodność oprogramowania Na początku lat 70-tych sformułowano pojęcie wiarygodności oprogramowania w celu oszacowania liczby błędów w oprogramowaniu jako metodzie mierzenia jego jakości. Można ją określić jako prawdopodobieństwo, iż oprogramowanie będzie działać w określonym przedziale czasu bez żadnego przestoju, ważone przez koszt użytkownika każdego przestoju [20]. Inne źródło [12] podaje, iż jest to stopień w jakim systemy, komponenty lub procesy producenta oprogramowania potrafią spełniać określone wymagania oraz potrzeby i oczekiwania użytkowników. Istnieje kilka modeli wiarygodności, które można sklasyfikować w trzech grupach: skończone i nieskończone [19], statyczne i dynamiczne [5], deterministyczne i probabilistyczne [21].

4 Modele deterministyczne są wykorzystywane do badania liczby różnych operatorów i operandów w programie, jak również do liczby błędów i liczby instrukcji maszynowych. Miary wydajności w grupie modeli dynamicznych są otrzymywane poprzez analizę struktury programu i nie biorą pod uwagę żadnych losowych zdarzeń. Dwie dobrze znane miary to metryka Halstead a i cyklomatyczna metryka McCabe a. Miarę złożoności cyklomatycznej, która bazuje na teorii grafów, McCabe przedstawił w 1976 roku [21]. Jest to liczba liniowo niezależnych ścieżek, które składają się na program komputerowy. W celu obliczenia miary M dla programu komputerowego przedstawionego w formie grafu lub diagramu przepływu należy skorzystać ze wzoru (8): gdzie: M= V(G)=e-n+2p (8) V(G) to cyklomatyczna liczba grafu G programu e to liczba krawędzi grafu n to liczba węzłów grafu p to liczba niepołączonych części grafu Istnieje prosta zależność pomiędzy miarą M i liczbą binarnych decyzji BD, gdyż zachodzi równość M=BD+1. Podobnie jak w przypadku innych wczesnych miar jakości, które koncentrują się na samych programach lub nawet ich modułach, ukryte jest źródło złożoności architektonicznej, czyli powiązania między modułami. Według Kana, oprócz długości modułu, najważniejszym predyktorem częstotliwości defektów jest ogólna liczba zmian projektowych oraz poziom złożoności, niezależnie od sposobu ich obliczania [13]. 7. Miary punktów funkcyjnych Dwa przedstawione podejścia Halstead a i McCabe a reprezentują ilościowe podejście do wymiarowania oprogramowania. Miary jakości bazujące pośrednio lub bezpośrednio na liczeniu wierszy kodu programu lub modułów są niewystarczające [12]. Miary te możemy określić jako substytuty wskaźników liczby okazji do popełnienia błędu z perspektywy implementacji kodu źródłowego programu. Metoda punktów funkcyjnych zdefiniowana przez Albrechta powstała w wyniku kilkuletnich doświadczeń przy opracowywaniu systemów informatycznych z zakresu przetwarzania danych [26]. Punkty funkcyjne możemy określić jako znaczące grupy mierzalnego kodu z perspektywy użytkownika a nie programisty. Uwzględniają one potrzeby użytkownika oraz zebraną w trakcie analizy wymagań funkcjonalność - nie są wyłącznie wskaźnikiem ukończenia go a posteriori przez programistę [12]. Zaproponowana przez Albrechta typowa miara punktów funkcyjnych (ang. function point metric) to ważona suma pięciu składników, które cechują aplikację [12,26]: 4 x liczba wejść zewnętrznych do systemu (lub typów transakcji), 5 x liczba typów lub raportów zewnętrznych, 10 x liczba wewnętrznych plików logicznych (zbiorów danych), 7 x liczba zewnętrznych plików interfejsu (zbiorów danych),

5 4 x liczba obsługiwanych zewnętrznych zapytań do systemu. Metoda ta szybko zdobyła dużą popularność i jest dalej rozwijana przez organizację IFPUG (ang. International Function Point Users Group), która opracowała również jej standard [11]. Wykorzystywana na przestrzeni czasu przez wytwórców oprogramowania bardzo dużych systemów informatycznych (1000 i więcej punktów funkcyjnych), metoda ta wykazuje wysoki poziom powtarzalności i przydatności [12]. 8. Miary zadowolenia użytkownika i dostępności Grupa miar prezentowana jako ostatnia swoją uwagę skupia na użytkowniku końcowym i na jego ocenie działania, niezawodności i stabilności oprogramowania w codziennym użytkowaniu. Zalecana jest tu jednak ostrożność, gdyż problemy z systemem nie koniecznie mogą wynikać z błędów w aplikacji, a wynikają z niewiedzy użytkowników. Zwykle satysfakcja klienta mierzona jest wedle pięciopunktowej skali [12]: bardzo zadowolony, zadowolony, obojętny, niezadowolony, bardzo niezadowolony. Wielowymiarowa ocena oprogramowania przez klientów odbywa się poprzez kwestionariusze. Firma IBM stosuje model CUPRIMDA w którym ocenie poddawane są: możliwości (ang. categoriescapability), łatwość użycia (ang. usability), wydajność (ang. performance), niezawodność (ang. reliability), łatwość instalacji (ang. installability), łatwość konserwacji (ang. maintainability), dokumentację (ang. documentation), dostępność (ang. availability). Z kolei firma Hewlett-Packard stosuje model FURPS w którym ocenie poddawane są: możliwości (ang. categoriesfunctionality), użyteczność (ang. usability), niezawodność (ang. reliability), wydajność (ang. performance), łatwość obsługi (ang. serviceability).

6 Niektórzy producenci stosują uproszczony ogólny wskaźnik zadowolenia OWZ (ang. net satisfaction index) w celu porównania różnych produktów ze sobą. Można wyróżnić w nim następujące wagi: w pełni zadowolony - 100% zadowolony - 75% obojętny - 50% niezadowolony - 25% całkowicie niezadowolony - 0% Pomimo tego, iż wskaźnik ten jest powszechnie stosowany, nie wskazuje dokładnie na źródło problemu. 9. Podsumowanie W pracy dokonano przeglądu kluczowych miar służących ocenie oprogramowania. Jest to aktualny problem biorąc pod uwagę obecne koszty zakupu i utrzymania systemów informatycznych. Obecnie często podejmowaną kwestią jest poziom na jakim powinna być dokonywana ocena. Pierwsze miary stosowane były do oceny na poziomie kodu źródłowego i koncentrowały się na liczbie błędów i defektów. Rozwój języków programowania i tym samym kompilatorów, przyniósł bogatsze biblioteki standardowych funkcji, makroinstrukcje, czy dyrektywy kompilacji. Wzbogaceniu języka, szczególnie w środowisku graficznym, udoskonalono obudowę środowiska pracy. Do kompilatora włączono edytor, konsolidator oraz debugger - w jednym zintegrowanym pakiecie umieszczono wszystkie narzędzia pracy programisty. Liczba błędów na poziomie kodu źródłowego znacznie się zmniejszyła - tym samym ocena w oparciu o takie miary okazała się być niewystarczająca. Wraz z dynamicznym postępem w dziedzinie języków programowania, towarzyszyły temu zmiany w podejściu do oceny oprogramowania. Zaproponowano podejście ilościowe, biorąc pod uwagę liczbę funkcji i tokenów, woluminu i ostatecznie liczbę punktów funkcyjnych. Profesor Halstead, uważany za ojca nauki o miarach oprogramowania, zaproponował nowatorskie jak na swoje czasy podejście. Zaproponował cztery główne miary, z których wyprowadził siedem pochodnych wzorów między takimi relacjami jak słownik, długość, rozmiar, poziom, trudność i pracochłonność. Podejście to, nie sprawdza się jako bezpośrednie miary ilościowe, gdyż uniemożliwia przewidzenie rozmiaru i jakości programu na wystarczająco wczesnych etapach jego rozwoju. Kolejną opisaną w pracy miarą jest złożoność cyklomatyczna McCabe a. Z jej stosowania wynika zalecenie, aby nie tworzyć modułów większych niż 10 niezależnych ścieżek w grafie, reprezentujących przepływ sterowania w metodzie. Podobnie jak w przypadku innych wczesnych miar jakości, położono nacisk wyłącznie na programie i jego modułach, bez badania powiązań między modułami. Nowatorskie podejście zaproponował Allan Albrecht z firmy IBM, gdyż jego miara punktów funkcyjnych jest oceną funkcjonalności dostarczonej przez oprogramowanie. Odwrócony został kierunek oceny z perspektywy implementacji programu do potrzeb użytkownika. Obecnie jest to ciągle rozwijane stanowisko, gdyż pozwala na audyt projektów,

7 wybór systemów funkcjonujących systemów do reinżynierii oraz porównywania i oceny różnych ofert dostawców oprogramowania. Ostatnia grupa zaprezentowanych miar zadowolenia użytkownika, skupia swoją uwagę na ocenie działania, niezawodności, funkcjonalności i stabilności oprogramowania przez użytkownika końcowego. Złożoność dzisiejszych systemów oraz wysoka wydajność sprzętu komputerowego, są przesłankami do posługiwania się syntetycznymi miarami oceny oprogramowania. Należy zwrócić uwagę, iż słowo oprogramowanie może być niewystarczające do pełnego oddania skali przedmiotu oceny. W kontekście opisu specyfikacji i wymagań używa się pojęcia technologii informatycznej, które wydaje się szerzej obejmować zagadnienia charakterystyki dzisiejszego oprogramowania. Zauważalny jest rozwój nowej nauki o miarach architektury oprogramowania. Co zaskakujące, odbywa się to w obliczu braku powszechnie przyjętych definicji takiej architektury i pojęć ściśle z nią powiązanych. W tym miejscu należy wymienić takie pojęcia jak technologia informatyczna, technologia informacyjna czy system informatyczny. Jak widać ocena oprogramowania jako niezależnych bytów zdaje się być nieaktualna, ze względu na coraz wyższą integrację różnego typu oprogramowania. Przyszłość zarządzania oprogramowaniem sprowadza się do syntetycznej oceny całych technologii informatycznych oraz zarządzania ich portfelem. Bibliografia [1] Albrecht A. J.: Measuring application development productivity. Proceedings of the IBM Applications Development Joint SHARE/GUIDE Symposium, Monterrey 1979, s [2] Basili V. R., Reiter R. W.: An investigation of human factors in software development. IEEE Computer, 1979 nr 12(12), s [3] Boehm B. W., Brown J. R., Kaspar H., Lipow, M.: Characteristics of software quality. Redondo Beach 1973, TRW Corporation (TRW-SS-73-09). [4] Cavano J. P., McCall, J. A.: A framework for the measurement of software quality. Proceedings of the Software Quality Assurance Workshop on Functional and Performance Issues, San Diego 1978, s [5] Conte S. D., Dunsmore H. E., Shen V. Y.: Software engineering metrics and models. Benjamin Cummings, Menlo Park [6] Dzida W., Herda S., Itzfeldt W. D.: User perceived quality of interactive systems. Proceedings of the Third International Conference on Software Engineering, Atlanta 1978, s [7] Gaffney J. E.: Metrics in software quality assurance. Proceedings of the ACM SIGMETRICS Workshop/Symposium on Measurement and Evaluation of Software Quality, Las Vegas 1981, Nevada, s [8] Gilb T.: Software metrics. Winthrop Publishers, Cambridge [9] Grady R. B., Caswell R. B.: Software metrics: Establishing a company wide program. Englewood Cliffs, Prentice Hall, New York [10] Halstead M. H.: Elements of software science. Elsevier, New York [11] http: Function Point Counting Practices Manual. Release 4.1, 5 lipiec 2009.

8 [12] Jayaswal B. K., Patton P. C.: Oprogramowanie godne zaufania. Metodologia, techniki i narzędzia projektowania, Helion, Gliwice [13] Kan S. H.: Metrics and Models in Software Quality Engineering, Pearson Education, Singapur [14] Kan S. H.: Metrics and models in software quality engineering. Addison-Wesley [15] Lipow M.: Number of faults per line of code. IEEE Transactions on Software Engineering, 1982 nr 8(4), s [16] McCabe T. J.: A complexity measure. IEEE Transactions on Software Engineering, 1976 nr 2(4), s [17] McIlroy M. D.: Macro instruction extensions of compiler languages. Communications of the ACM, 1960 nr 3(4), s [18] Motley R. W., Brooks W. D.: Statistical prediction of programming errors. Griffis AFB, New York [19] Musa J. D.: Software reliability engineering. McGraw Hill, New York [20] Myers G. J.: Software reliability: Principles and practices. John Wiley & Sons, New York [21] Pham H.: System Software Reliability, Springer, London [22] Rubey R. J., Hartwick R. D.: Quantitative measurement of program quality. Proceedings of the 23rd ACM National Conference, Washington 1968, s [23] Shen V. Y., Yu T. J., Thebaut S. M., Paulsen L. R.: Identifying error prone software: An empirical study. IEEE Transactions on Software Engineering, 1985 nr 11(4), s [24] Shooman M. L., Bolsky M. I.: Types, distribution, and test and correction times for programming errors. Proceedings of the International Conference on Reliable Software, Los Angeles 1975, s [25] Swanson E. B.: The dimensions of maintenance. Proceedings of the Second International Conference on Software Engineering, San Francisco 1976, s [26] Szyjewski Z.: Wymiarowanie zmian w projektach informatycznych [w]: Zarządzanie wiedzą i technologiami informatycznymi. Automatyka i Informatyka nr 5. Technologie Informacyjne: Zarządzanie. Orłowski C., Kowalczuk Z., Szczerbicki E. (red.), Pomorskie Wydawnictwo Naukowo-Techniczne PWNT, Gdańsk 2009, s Paweł WEICHBROTH*, Cezary ORŁOWSKI** * Zakład Zarządzania Technologiami Informatycznymi, Wydział Zarządzania i Ekonomii, Politechnika Gdańska, pwi@zie.pg.gda.pl ** Zakład Zarządzania Technologiami Informatycznymi, Wydział Zarządzania i Ekonomii, Politechnika Gdańska, cor@zie.pg.gda.pl