1 / 23

Pomiary w inżynierii oprogramowania

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Pomiary w inżynierii oprogramowania. Cel pomiarów. ocena jakości produktu ocena procesów (produktywności ludzi) stworzenie podstawy dla szacowania ocena korzyści (nowe techniki i narzędzia) ocena potrzeby nowych narzędzi lub szkoleń.

orly
Download Presentation

Pomiary w inżynierii oprogramowania

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Pomiary w inżynierii oprogramowania

  2. Cel pomiarów • ocena jakości produktu • ocena procesów (produktywności ludzi) • stworzenie podstawy dla szacowania • ocena korzyści (nowe techniki i narzędzia) • ocena potrzeby nowych narzędzi lub szkoleń Pomiary w inżynierii oprogramowania

  3. Kategorie pomiarów • pomiary bezpośrednie (np. długość, czas) • pomiary pośrednie Pomiary w inżynierii oprogramowania

  4. Metryki techniczne Metryki jakości Metryki produktywności Metryki zorientowane na rozmiar Metryki zorientowane na funkcje Metryki zorientowane na ludzi Kategorie pomiarów w inżynierii oprogramowania • Metryki techniczne • złożoność, modularność • Metryki jakości • spełnienie wymagań użytkownika • Metryki produktywności • wydajność procesu wytwarzania • Metryki zorientowane na rozmiar • odnoszą się do rozmiaru kodu • Metryki zorientowane na funkcje • odnoszą się do liczby funkcji • Metryki zorientowane na ludzi • odnoszą się do pracy ludzkiej Pomiary w inżynierii oprogramowania

  5. Metryki zorientowane na rozmiar (1) • Metryki bezpośrednie • wielkość kodu [KLOC] • wielkość dokumentacji [strony] • pracochłonność [osobomiesiące] • koszt • liczba defektów Pomiary w inżynierii oprogramowania

  6. Metryki zorientowane na rozmiar (2) • Metryki pośrednie • produktywność = wielkość kodu/pracochłonność • awaryjność = ilość defektów/wielkość kodu • kosztowność = koszt/wielkość kodu • udokumentowanie = wielkość dokumentacji/wielkość kodu Pomiary w inżynierii oprogramowania

  7. Za wielkość kodu może być łatwo policzona wielkość kodu jest używana w wielu modelach szacowania oprogramowania wpływ wielkości kodu jest dobrze udokumentowany Przeciw wielkość kodu jest zależna od języka programowania zwięzłe, krótkie programy mają gorsze wskaźniki nie nadają się dla języków nieproceduralnych szacowanie wielkości kodu jest konieczne przed rozpoczęciem kodowania Metryki zorientowane na rozmiar (za i przeciw) Pomiary w inżynierii oprogramowania

  8. Metryki zorientowane na funkcje • punkty funkcyjne (FP – Function Points) • punkty funkcjonalne (FP – Feature Points) Pomiary w inżynierii oprogramowania

  9. Punkty funkcyjne (1) Pomiary w inżynierii oprogramowania

  10. Punkty funkcyjne (2) Fi: 0 1 2 3 4 5 brak wpływu incydentalnie umiarkowanie średnio znacząco zasadniczo • Czy system wymaga wiarygodnego zachowywania i odzyskiwania danych? • Czy wymagane jest przekazywanie danych? • Czy występują funkcje przetwarzania rozproszonego? • Czy wydajność jest krytyczna? • Czy system ma pracować w istniejącym, trudnym środowisku operacyjnym? • Czy system wymaga wprowadzania danych on-line? • Czy dane wprowadzane on-line wymagają transakcji wejściowych zbudowanych na wielu ekranach lub operacjach? • Czy główne pliki są aktualizowane on-line? • Czy wejścia, wyjścia, pliki lub interakcje są złożone? • Czy wewnętrzne przetwarzanie jest złożone? • Czy kod jest zaprojektowany do powtórnego wykorzystania? • Czy konwersja i instalacja jest zawarta w projekcie? • Czy system został zaprojektowany dla wielu instalacji w różnych organizacjach? • Czy aplikacja jest zaprojektowana w sposób przyjazny dla użytkownika i tak, by ułatwiać wprowadzanie zmian? Pomiary w inżynierii oprogramowania

  11. Punkty funkcyjne (3) FP = liczba punktów × [0,65 + 0,01 x Sum(Fi)] • Metryki pośrednie • produktywność = FP/pracochłonność • awaryjność = ilość defektów/FP • kosztowność = koszt/FP • udokumentowanie = wielkość dokumentacji/FP Pomiary w inżynierii oprogramowania

  12. Punkty funkcjonalne Pomiary w inżynierii oprogramowania

  13. Za są niezależne od języka programowania nadają się zarówno dla języków proceduralnych jak i nieproceduralnych mogą być stosowane we wczesnych fazach planowania Przeciw obliczenia mają charakter częściowo subiektywny dane są trudne do zebrania nie mają bezpośredniego znaczenia fizycznego Punkty funkcyjne/ funkcjonalne (za i przeciw) Pomiary w inżynierii oprogramowania

  14. Zależność LOC/FP dla różnych języków programowania Pomiary w inżynierii oprogramowania

  15. Metryki złożoności • metryka Halsteada • metryka cyklometryczna McCabe’a Pomiary w inżynierii oprogramowania

  16. Metryki Halsteada (1) n1 – liczba różnych operatorów w programie n2 – liczba różnych operandów w programie N1 – całkowita liczba operatorów N2 – całkowita liczba operandów Pomiary w inżynierii oprogramowania

  17. Metryki Halsteada – przykład (1) Sub Sort(X,N) Dim X(N) If N<2 Return For I = 2 To N For J = 1 To I IF X(I)<X(J) Then Save = X(I) X(I) = X(J) X(J) = Save End If Next Next End Sub Pomiary w inżynierii oprogramowania

  18. Metryki Halsteada – przykład (2) Sub Sort(X,N) Dim X(N) If N<2 Return For I = 2 To N For J = 1 To I IF X(I)<X(J) Then Save = X(I) X(I) = X(J) X(J) = Save End If Next Next End Sub Pomiary w inżynierii oprogramowania

  19. Metryki Halsteada (3) • długość programu: N = N1 + N2 • rozmiar słownika:n = n1 + n2 • objętość algorytmu: V = N log2(n) • stosowana zamiast LOC • objętość funkcji powinna być od 20 do 1000 • objętość pliku powinna być od 100 do 8000 • poziom trudności: D = (n1/2)*(N2/n2) • wyznacza stopień odporności na błędy • poziom programu: L = 1/D • wysiłek implementacyjny: E = V*D • czas na implementację: T = E/18 (w sekundach) • liczba potencjalnych błędów: B = E (2/3) / 3000 Pomiary w inżynierii oprogramowania

  20. Metryka złożoności cyklometrycznej McCabe’a R1 R2 R5 v(G) = 5 R3 R4 oznacza liczbę potencjalnych ścieżek wykonania dla funkcji powinna nie większa niż 15 dla plików powinna nie większa niż 100 Pomiary w inżynierii oprogramowania

  21. Spójność grafów • Spójność grafu • spójność słaba • nierozdzielność (węzłowa, krawędziowa) • spójność silna Pomiary w inżynierii oprogramowania

  22. Ankiety (kwestionariusze) • Brak metryk obiektywnych • Duża subiektywność • Wymuszenie obiektywności – pytania tak/nie • Duża liczba pytań • niechęć do odpowiedzi • nierzetelność odpowiedzi • Wiarygodność oceny • Duża liczba oceniających Pomiary w inżynierii oprogramowania

  23. Bibliografia • Pressman R.S., Software engineering. A practitioner’s approach, McGraw-Hill, International Edition, 1992 • Halstead Maurice, Elements of Software Science, Elsevier Science Ltd, 1977 • http://www-ivs.cs.uni-magdeburg.de/sw-eng/us/experiments/hals/ • http://yunus.hacettepe.edu.tr/~sencer/complexity.html Pomiary w inżynierii oprogramowania

More Related