Personal Software Process cz. I

Transkrypt

1 Personal Software Process cz. I Witam serdecznie! Tematem tego wykładu bdzie metodyka wytwarzania oprogramowania zwana Personal Software Process, czyli Osobisty proces programistyczny. Na slajdzie umieciłem zdjcie Pittsburgha, gdy metodyka ta podobnie, jak CMMI jest sztandarowym produktem Software Engineering Institute majcego sw siedzib włanie w Pittsburghu, w stanie Pensylwania. W dalszej czci wykładu bd uywał oryginalnej nazwy Personal Software Process lub skróconej PSP. 1

2 Plan wykładów! " # $ $% & ' (! ) * +, " # $ $% & ' (! ) * +,!!! - %. & ' / & & % % - 0 1) ) ) % * 8 " # % % 9 : " & % - % ; Personal Software Process, cz. I (2) W trakcie ostatnich dwóch wykładów mówilimy o metodyce zarzdzania przedsiwziciami PRINCE2. Personal Software Process jest w pewnym sensie konkurencyjn metodyk wzgldem PRINCE2 z tym, e: Dotyczy pojedynczej osoby a nie całego zespołu. Jest silnie ukierunkowany na tworzenie oprogramowania. Problematyce PSP powicimy dwa wykłady. 2

3 Syndrom LOOP Loop Late (póno) Over budget (przekroczony budet) Overtime (nadgodziny) Poor quality (kiepska jako) Personal Software Process, cz. I (3) Zmor wielu kierowników przedsiwzi programistycznych jest LOOP. Loop po angielsku oznacza ptl. Ale LOOP oznacza te cztery podstawowe bolczki zwizane z wytwarzaniem oprogramowania. Oprogramowanie jest dostarczane póno, bardzo czsto znacznie póniej ni obiecywał to na pocztku wykonawca std L, jak Late. Ponadto bardzo czsto dochodzi do przekroczenia budetu przedsiwzicia std pierwsze O, jak Over budget. Programici w bardzo wielu firmach pracuj w nadgodzinach, rezygnujc z ycia osobistego std drugie O, jak Overtime. I mimo ich powicenia produkt ich pracy jest czsto (w ocenie uytkowników kocowych) kiepskiej jakoci std P, jak Poor quality. 3

4 Wprowadzenie Watts Humphrey : IBM Corporation, Director of Programming Quality and Process Fellow of the Software Engineering Insititue (SEI) at Carnegie Mellon University A Discipline for Software Engineering, Addison Wesley, 1995 Personal Software Process, cz. I (4) Specjalici cigle poszukuj metod i narzdzi, które miałyby zaradzi syndromowi LOOP. Jedn z takich propozycji jest PSP. Autorem metodyki PSP jest Watts Humphrey. Przez 27 lat pracował w firmie IBM, gdzie był m.in. dyrektorem ds. jakoci i procesu programowania. W drugiej połowie lat 80-tych przeszedł do SEI. W 1995 roku opublikował ksik pt. A Discipline for Software Engineering (Dyscyplina w inynierii oprogramowania), w której przedstawił szczegółowy opis metodyki PSP. Wykład opiera si na tej ksice. 4

5 Czym jest PSP? PSP: samodoskonalenie PSP: jak podejmowa i wypełnia zobowizania PSP: formularze + procedury Czego brak: inynieria wymaga, zarzdzanie konfiguracj, zarzdzanie ryzykiem Personal Software Process, cz. I (5) Czym jest PSP? Jest to metoda samodoskonalenia dla programistów. Uczy te, jak podejmowa zobowizania i je wypełnia. Ale przez wiele osób PSP jest postrzegana przede wszystkim jako zestaw formularzy i procedur. PSP nie obejmuje wszystkich zagadnie zwizanych z wytwarzaniem oprogramowania. Nie proponuje adnych metod zwizanych z inynieri wymaga PSP jest zorientowane na programist i zakłada si, e specyfikacja wymaga jest ju gotowa lub na tyle prosta, e bardziej zaawansowane metody inynierii wymaga nie s potrzebne i programista moe j sam napisa. Nie ma te w PSP propozycji praktyk dotyczcych zarzdzania konfiguracj i niewiele si mówi o zarzdzaniu ryzykiem. 5

6 Wprowadzenie Personal Software Process, cz. I (6) Jak ju wspomniałem, metodyka PSP została stworzona przez pracownika SEI. Jak pamitamy z wykładu dotyczcego CMMI, w SEI powstał te 5-poziomowy model dojrzałoci CMMI. Nic wic dziwnego, e PSP swoj struktur przypomina CMMI. PSP składa si z czterech poziomów, z których trzy pierwsze maj po dwie warstwy. 6

7 Wprowadzenie Rozwój cykliczny Szablony projektowe Przegldy kodu i proj. Planowanie zada i harmon. Szacowanie rozmiaru + raport tst Stand. kodu + Pomiar rozm. + PS Rejestry czasu i defektów 3.Cykliczny 2.Jakoci 1.Planowania 0.Bazowy Personal Software Process, cz. I (7) Najniszy, zerowy, poziom nazywa si Bazowym. Pierwsza jego warstwa uczy jak korzysta z rejestru czasu pracy i rejestru defektów. Druga warstwa poziomu Bazowego obejmuje standard kodowania, pomiar rozmiaru tworzonego oprogramowania i propozycj samodoskonalenia (PS). Drugi poziom dotyczy planowania. Pierwsza jego warstwa obejmuje szacowanie rozmiaru tworzonego oprogramowania i raporty dotyczce testowania. Druga warstwa jest zwizana z planowaniem zada i tworzeniem harmonogramów. Trzeci poziom jest zwizany z jakoci tworzonego oprogramowania. Pierwsza jego warstwa dotyczy przegldów kodu i projektu oprogramowania. W ramach drugiej warstwy Watts Humphrey proponuje korzystanie z opracowanych przez niego szablonów projektowych obejmujcych cztery notacje dotyczce czterech rónych aspektów oprogramowania. Wobec pojawienia si w 1997 roku jzyka UML, notacje zaproponowane przez Humphrey a straciły na atrakcyjnoci. Z drugiej strony nie trudno zmodyfikowa PSP tak, aby oprze szablony projektowe na jzyku UML. Najwyszy poziom dotyczy tworzenia przez pojedynczego programist duego oprogramowania rzdu tysicy linii kodu. Na tym poziomie Watts Humphrey proponuje stosowanie podejcia cyklicznego (inni nazywaj to podejciem iteracyjnym). 7

8 Plan wykładu < < " # < " # $ < " % < < & #% < % Personal Software Process, cz. I (8) Szczegółowe omawianie PSP rozpoczn od najniszego poziomu, czyli od poziomu Bazowego. Przedstawi proces bazowy wchodzcy w skład PSP. Potem zaprezentuj rejestry czasu i defektów, które odgrywaj w PSP bardzo wan rol. Nastpnie przejd do zagadnie pomocniczych dotyczcych definicji rozmiaru kodu, standardu kodowania i propozycji samodoskonalenia. Zakocz ten pierwszy z dwóch wykładów na temat PSP przedstawieniem metody PROBE słucej do szacowania rozmiaru kodu. 8

9 Plan wykładu < < " # < " # $ < " % < < & #% < % Personal Software Process, cz. I (9) Zacznijmy zatem od przedstawienia procesu bazowego. 9

10 Proces bazowy Skrypty & & % Planowanie Projekt Kodowanie Kompilacja Testowanie Postmortem ' Rej. Podsum. przeds. " & & % Personal Software Process, cz. I (10) Jak ju wspomniałem, w PSP zakłada si, e wymagania s ju gotowe (np. spisane przez analityka) lub te na tyle proste, e programista sam moe je sformułowa na podstawie opisu problemu. Na tej podstawie programista planuje swoj prac, opracowuje projekt i pisze kod. Po zakoczeniu kodowania przechodzi do kompilacji. W trakcie kompilacji mog si ujawni róne błdy składniowe, które programista musi usun. Kompilacja koczy si po pierwszej udanej kompilacji. Potem nastpuje testowanie. Obejmuje ono równie usuwanie błdów wykrytych w trakcie testowania. Ostatni faz jest tzw. postmortem. W trakcie tej fazy nastpuje podsumowanie dowiadcze zebranych w trakcie pracy nad oprogramowaniem. Dla kadej fazy Watts Humphrey opracował skrypt opisujcy potrzebne dane wejciowe, procedur zgodnie z któr naley t faz wykona oraz dane wyjciowe, bdce wynikiem tej fazy. Dane charakteryzujce przebieg kadej fazy umieszcza si w tzw. rejestrach, których szablony równie zostały opracowane przez Wattsa Humphrey ego. S to głównie rejestry czasu i rejestry defektów. Za chwil nieco dokładniej o nich powiem. W fazie postmortem dane zawarte w rejestrach zostaj przeanalizowane i przedstawione w formie Raportu podsumowania. Raport ten jest odpowiednikiem Raportu dowiadczenia w PRINCE2 (Lessons Learned Report). 10

11 Plan wykładu < < " # < " # $ < " % < < & #% < % Personal Software Process, cz. I (11) W PSP s wykorzystywane dwa podstawowe rejestry: rejestr czasu i rejestr defektów. Omówi teraz pierwszy z nich. 11

12 Rejestr czasu Inynieria oprogramowania Klasyczne praktyki zarzdzania czasem Obserwuj zuycie czasu. Zasady skutecznego działania (75) Personal Software Process, cz. I (12) Rejestr czasu jest realizacj jednej z dobrych praktyk zarzdzania czasem, zgodnie z któr naley obserwowa zuycie czasu (mówilimy o tych sprawach w ramach przedmiotu Inynieria oprogramowania, na wykładzie powiconym zasadom skutecznego działania). 12

13 Rejestr czasu % ( ) ( & * Faza czy zadanie? Personal Software Process, cz. I (13) Przykładowy szablon rejestru czasu (dokładniej mówic, rejestru czasu pracy) jest przedstawiony na slajdzie. U góry jest miejsce na nazw programu i na dat. Załómy, e 20-tego maja pracowałem nad programem dotyczcym kolorowania grafów, który nazwałem KolorGraf. Wówczas w górnym wierszu rejestru czasu wpisałbym nazw programu i dat tak, jak to pokazano na slajdzie. Dane wpisywane w kolejnych kolumnach rejestru czasu pracy oznaczaj: Start Godzina rozpoczcia pracy. Przerwa Przerwy w pracy liczone w minutach. Stop Godzina zakoczenia pracy. Efektywny czas pracy liczony jako rónica midzy Stop a Start, pomniejszona o przerwy. Faza Nazwa fazy pracy nad programem lub jej skrót (Plan, Projekt, Kod itd.). Uwagi Dowolny komentarz. Najczciej jest to komentarz do przerwy w pracy (podaje z czego wynikała przerwa). Załómy, e o godzinie 9:10 rozpoczłem planowanie pracy nad programem KolorGraf. Wówczas w kolumnach Start i Faza wpisałbym dane pokazane na slajdzie. O 9:15 wpada szef i proponuje mi wyjazd na konferencj dotyczc inynierii oprogramowania. Nasza rozmowa trwa 9 minut. Po wyjciu szefa wpisuj w kolumnach Przerwa i Uwagi odpowiedni informacj. O 9:30 przychodzi kolega i prosi o poyczenie ksiki na temat specyfikacji wymaga za pomoc przypadków uycia. Poszukanie ksiki i zwizana z tym krótka rozmowa trwa 7 minut. Po wyjciu kolegi aktualizuj rejestr czasu tak, jak to pokazano na slajdzie. O 9:57 skoczyłem planowanie i wpisuj t godzin w kolumnie Stop. Jeli rejestr czasu jest zrealizowany za pomoc odpowiednio przygotowanego arkusza kalkulacyjnego, to efektywny czas pracy zostanie automatycznie obliczony. W przeciwnym razie musiałbym sam ten czas obliczy i wpisa go w kolumnie. Mona to zrobi od razu, albo w fazie postmortem. Przy okazji warto wspomnie, e w Internecie mona znale programy wspomagajce wpisywanie danych do rejestru czasu. Wystarczy nacinicie odpowiedniego klawisza myszy i dane na temat czasu s automatycznie zapamitywane. Załómy, e o 10:55 powtórnie zabrałem si za prac nad programem KolorGraf i do 12:50 projekt tego programu był gotowy. W midzyczasie miałem drug rozmow z szefem, która zajła mi 20 minut. Wówczas drugi wiersz rejestru czasu zostałby wypełniony w sposób taki, jak na slajdzie. Rejestr czasu przedstawiony na slajdzie ma pewn wad. Jest do wielu programistów, którzy nie pracuj zgodnie z fazami zaproponowanymi przez Wattsa Humprey a. Napisz fragment kodu, zaraz go skompiluj i przetestuj, potem dodadz nastpny fragment kodu itd. W trakcie pracy s tak skupieni na aspektach algorytmicznych, e nie maj ochoty ani energii prowadzi notatek na temat charakteru pracy, jaki w danej chwili wykonuj (nie obchodzi ich, czy w tej chwili jest to kodowanie, kompilacja, czy testowanie). W takiej sytuacji wersja rejestru czasu zaproponowana przez Wattsa Humphrey a jest nazbyt szczegółowa. 13

14 Rejestr czasu ) ( & + "#! Faza czy zadanie? Personal Software Process, cz. I (14) Dlatego warto zawsze podchodzi to tego typu spraw w sposób proaktywny i w razie potrzeby dostosowywa takie narzdzia, jak rejestr czasu do aktualnych potrzeb. Na przykład zamiast fazy mona wpisywa nazw zadania. Wtedy formularz rejestru czasu bdzie bardziej zwizany z danym dniem, a nie z programem. Na slajdzie jest przedstawiony rejestr czasu dotyczcy dnia 20. maja Jak wida, pojawił si tam wiersz dotyczcy zebrania na temat reorganizacji. Natomiast zniknła informacja nt. fazy pracy nad programem KolorGraf wida tylko ile czasu łcznie powiciłem na prac nad tym programem. 14

15 Plan wykładu < < " # < " # $ < " % < < & #% < % Personal Software Process, cz. I (15) Przejd teraz do omówienia rejestru defektów. 15

16 Rejestr defektów % ( ) ( / &. & - &, & & $%&'( Personal Software Process, cz. I (16) Przykładowy szablon tego rejestru został przedstawiony na slajdzie. W górnej czci formularza wpisuje si nazw programu (np. KolorGraf) i dat. W kolumnie Lp (Lp od Liczba Porzdkowa ) wpisuje si kolejny numer defektu. W ostatniej kolumnie, Opis, umieszcza si słowny opis znalezionego błdu, np. Brak rednika. W kolumnie Typ znajduj si liczby charakteryzujce typ błdu. Ta charakterystyka błdów jest oparta na klasyfikacji błdów zaproponowanej przez Rama Chillarege a. 16

17 Rejestr defektów ), 0 ), 1 " %,!A 23() % #0 % % 1 43( 53(! #0 # 1 63( & 0 # 1 7 3(! #0 $ #& % 1 83( & 0 % 9 : & $& 1 ; 3() 0 :< 1 =3(* #0 #& 9 1 > 3( % 0? : & % 9< 1 233(@ 0 % & 1 Personal Software Process, cz. I (17) W 1992 roku Ram Chillarege i jego koledzy z firmy IBM opublikowali w renomowanym czasopimie amerykaskim IEEE Transactions on Software Engineering tzw. ortogonaln klasyfikacj defektów programistycznych. Wyrónili dziesi głównych klas defektów. Po pierwsze, defekty mog by w dokumentacji zwizanej z oprogramowaniem. W przypadku samodokumentujcych si programów informacja o charakterze dokumentacyjnym jest zawarta głównie w komentarzach, ale take w komunikatach generowanych przez program. Po drugie, moemy mie do czynienia z błdami o charakterze składniowym (np. brak rednika na kocu instrukcji jzyka C). Mog te by błdy dotyczce integracji oprogramowania. Mog one dotyczy biblioteki podprogramów, zarzdzania wersjami i tym podobnych spraw. Kolejn grup stanowi defekty zwizane z instrukcj przypisania. Mog polega na niewłaciwej deklaracji zmiennej, czy te niewłaciwym rozumieniu zakresu zmiennej (która instancja zmiennej X jest w danym miejscu widoczna?). Defekty interfejsu najczciej dotycz deklaracji nagłówka funkcji (lub, ogólnie mówic, podprogramu) i jej parametrów. W programach wystpuje rónego rodzaju sprawdzanie (ang. checking). Defekty dotyczce sprawdzania mog polega np. na niewłaciwych komunikatach o błdach lub niewłaciwym sposobie sprawdzania danej zalenoci. Mog te by błdy dotyczce struktur danych i ich zawartoci. Inn kategori błdów wyodrbnion przez Chillarege a i jego kolegów s błdy dotyczce funkcji (podprogramów). S to rónego rodzaju błdy w obrbie funkcji, które nie s błdami interfejsu (50), czy te błdami dotyczcymi instrukcji przypisania (40). Mog to by np. defekty zwizane z logik przetwarzania w obrbie funkcji, niewłaciwym zorganizowaniem wywoła rekurencyjnych, czy te defekty dotyczce ptli (np. ptle z nieskoczon liczb powtórze). Mog te by defekty o charakterze systemowym. Na przykład mog w opracowywanym programie (systemie) istnie zalenoci czasowe. Defekt moe polega na tym, e czasami odpowied systemu zostaje wypracowana zbyt póno i która z tych zalenoci nie zostaje spełniona (jest to szczególnie wane we wszelkiego typu systemach sterowania). Mog te by problemy z dostpna pamici (program moe da wikszej pamici ni dostpna w systemie). Ostatnia kategoria dotyczy defektów rodowiska. Mog to by błdy kompilatora (tak jest - zdarzaj si błdy równie w kompilatorach), czy te błdy zawarte w testach. Tutaj te Chillarege umiecił błdy zwizane z projektem (design) całego oprogramowania (np. niewłaciwy podział kodu na moduły). 17

18 Rejestr defektów % ( ) ( / &. & - &, & & $%&'( 43( 63( & 0 # 1 7 3(! #0 $ #& % 1 ; 3() 0 :< 1 =3(* #0 #& 9 1 Personal Software Process, cz. I (18) Brak rednika jest typowym błdem składniowym, std te w kolumnie Typ wpisano warto 20. W kolumnie Wpro (Wpro jak WPROwadzenie) umieszczane s dane wskazujce faz pracy nad programem, w której wprowadzono defekt. 18

19 Rejestr defektów - % Planowanie Projekt Kodowanie Kompilacja Testowanie Postmortem ' Personal Software Process, cz. I (19) Jak ju wczeniej wspomniałem, w PSP proces tworzenia oprogramowania składa si z szeciu faz. Ostatnia faza, Postmortem, polega na podsumowaniu całego procesu i ma charakter administracyjny. Zatem w tej fazie nie mona wstawi adnego błdu do oprogramowania (oprogramowanie jest ju gotowe). 19

20 Rejestr defektów - % Planowanie Projekt Kodowanie Kompilacja Testowanie Postmortem ' ( ) (), (, ( &. (. Personal Software Process, cz. I (20) Zatem w rachub wchodzi pi pierwszych faz. Humphrey oznacza fazy całymi wyrazami. Myl, e mona te uy pojedynczych liter pochodzcych od ich angielskich nazw tak jak to pokazano na slajdzie. Jest kłopot z kompilacj, bo Coding i Compilation zaczynaj si na C. Mona przyj, e M bdzie oznacza kompilacj. 20

21 Rejestr defektów % ( ) ( / &. & - &, & & * ) $%&'( 43( 63( & 0 # 1 7 3(! #0 $ #& % 1 ; 3() 0 :< 1 =3(* #0 #& 9 1 ( ) (), (, ( &. (. Personal Software Process, cz. I (21) Jeli rednik pominito w fazie kodowania, to w kolumnie Wpro powinna si pojawi litera C oznaczajca faz kodowania. Kolumna Usu (jak USUnicie) pokazuje faz, w której dany błd usunito. Jak wida, brak rednika usunito w fazie kompilacji. W kolumnie Czas odnotowuje si czas, jaki był potrzebny na zidentyfikowanie i usunicie danego błdu. Jak wida, w przypadku braku rednika wystarczyła 1 minuta by to wykry (za pomoc kompilatora) i usun. 21

22 Rejestr defektów % ( / &. & - &, * ) * ) & ) ( & $%&'( $%+!%, 43( 63( & 0 # 1 7 3(! #0 $ #& % 1 ; 3() 0 :< 1 =3(* #0 #& 9 1 ( ) (), (, ( &. (. Personal Software Process, cz. I (22) W trakcie kompilacji (Usu = M) zauwaono i usunito drugi błd (Lp = 2) polegajcy na braku deklaracji zmiennej (jest to błd składniowy, std Typ = 20). Programista pominł deklaracj zmiennej w trakcie kodowania, std Wpro = C. Usunicie tego błdu zajło 1 minut. 22

23 Rejestr defektów % ( / &. & - &, * ) * ) ) ) & ) ( & $%&'( $%+!%, $%&-( 43( 63( & 0 # 1 7 3(! #0 $ #& % 1 ; 3() 0 :< 1 =3(* #0 #& 9 1 ( ) (), (, ( &. (. Personal Software Process, cz. I (23) Czasami tak si, niestety, zdarza, e usuwajc jeden błd wprowadzamy inny. Nasz programista wprowadzajc brakujca deklaracj zmiennej (by usun defekt nr 2) zapomniał wprowadzi przecinek oddzielajcy nazwy zmiennych midzy sob i tak powstał defekt nr 3. Jeli taka sytuacja ma miejsce, to zgodnie z PSP wpisujemy do kolumny Popr numer defektu, w którego trakcie usuwania wprowadzilimy dany defekt. Poniewa defekt nr 3 powstał w trakcie usuwania defektu nr 2, zatem w ostatnim wierszu Popr = 2. 23

24 Rejestr defektów % ( ) ( / &. & - &, & & * ) $%&'( * ) $%+!%, ) ) $%&-( Personal Software Process, cz. I (24) Wydaje mi si, e rejestr defektów zaproponowany przez Humphrey a jest troch nadto skomplikowany i zbyt detaliczny. To prawda, e jak bdziemy mieli dane dotyczce typu kadego defektu, fazy jego wprowadzenia i usunicia oraz czasu, jaki zajło jego usunicie, to charakterystyka procesu programowania bdzie bardzo dokładna. Ale, jak si przekonamy, w samym PSP nie ma mechanizmów, które robiłyby uytek z tych danych. Dlatego te uwaam, e warto pomyle nad uproszczeniem rejestru defektów. 24

25 Uproszczony rejestr defektów % ), B C &.%/!%!#01%234,%2534% Personal Software Process, cz. I (25) Rejestr defektów mona by potraktowa, jako rejestr dowiadczenia w PRINCE2 (Lessons Learned Log). Zatem powinny do niego trafia nie drobne defekty, których poprawienie jest oczywiste, lecz takie, które kosztowały sporo czasu. Na slajdzie pokazana jest propozycja uproszczonego rejestru defektów. Zawiera on jedynie cztery kolumny, do których wpisuje si nazw programu, dat wykrycia błdu, czas jaki zajło jego poprawianie (liczony nie w minutach, lecz w godzinach, bo chodzi nam o czasochłonne defekty) i opis defektu. 25

26 Plan wykładu < < " # < " # $ < " % < < & #% < % Personal Software Process, cz. I (26) Zastanówmy si teraz, jaka miara rozmiaru kodu bdzie najwłaciwsza z punktu widzenia PSP. 26

27 Rozmiar kodu & % #, #, D / /, /, Personal Software Process, cz. I (27) Generalnie miary oprogramowania mona podzieli na funkcjonalne i bazujce na cechach kodu. Miary funkcjonalne opieraj si na specyfikacji wymaga i (ewentualnie dodatkowo) na załoonej architekturze systemu. Najbardziej znan miar funkcjonaln s punkty funkcyjne opracowane w firmie IBM przez Allana Albrechta pod koniec lat 70-tych ubiegłego wieku. Jest to do skomplikowana technika pomiaru oprogramowania uwaa si, e jej opanowanie wymaga około roku dowiadcze z mierzeniem rónego typu programów. Przykładem miary bazujcej na cechach kodu moe by tzw. złoono cyklomatyczna znana równie jako miara McCabe a. Tutaj rozmiar oprogramowania jest mierzony liczb rozgałzie w programie. Miara ta jest zdefiniowana w prosty i jasny sposób tak, e nawet pocztkujcy programista jest w stanie, w krótkim czasie, napisa dla danego jzyka program obliczajcy t miar. Jednake najprostsz i (prawdopodobnie włanie dlatego) najbardziej popularn miar kodu s linie kodu. Oznacza si je jako LOC, od angielskiego Lines of Code. W kontekcie PSP bardzo nam zaley na szacowaniu pracochłonnoci, std te bd nas interesowały tylko te linie kodu, które zostały napisane przez programist tzw. ródłowe linie kodu, w skrócie SLOC od angielskiego Source Lines of Code. Linie kodu, które zostały wygenerowane przez takie narzdzia jak YACC nie bd nas interesowały. 27

28 Rozmiar kodu " % E!F,. " F432> > 4 & (GG % G& G % G> 4 & G& G43 > 4 & Personal Software Process, cz. I (28) Oczywicie, kada miara musi by dobrze okrelona. Naley zatem precyzyjnie okreli, jak bd liczone linie kodu. Czy na przykład bd wliczane puste linie, linie zawierajce tylko komentarz, linie zawierajce tylko nawiasy klamrowe w jzyku C lub te tylko słowa BEGIN i END w Pascalu itd. Robert Park z SEI opracował bardzo dokładn metod definiowania miary oprogramowania opartej na liniach kodu na slajdzie jest podany adres raportu zawierajcego opis tej metody. Jeli linie kodu nie bd miar produktywnoci programisty (wykorzystywan np. przez jego szefa) lecz bd wykorzystywane przez samego programist do szacowania pracochłonnoci, to uwaam, e mona przyj jako miar fizyczne linie kodu ródłowego. Jest to bardzo prosta miara - wystarczy przej na koniec pliku i wikszo edytorów pokae nam numer ostatniej linii. Jeeli styl kodowania (tzw. standard kodowania, o którym bdziemy za chwil mówi) bdzie przez cały czas ten sam, to ta miara mimo, i tak prosta nie powinna wnosi istotnie wikszego błdu do szacowania, ni bardziej wyrafinowane definicje. 28

29 Plan wykładu < < " # < " # $ < " % < < & #% < % Personal Software Process, cz. I (29) Przejdmy teraz do omówienia standardu kodowania. Ma on dwojakie znaczenie: z jednej strony zmniejsza błd szacowania pracochłonnoci w oparciu o fizyczne linie kodu ródłowego, a z drugiej strony zwiksza czytelno programów, przez co w sposób poredni przyczynia si do podniesienia ich jakoci. 29

30 Standard kodowania /*************************************************************/ /* Program: KolorGraf */ /* Autor: Jerzy Nawrocki */ /* Data: */ /* Funkcja: Program koloruje wezly podanego grafu nieskiero- */ /* wanego w taki sposób, aby kazda para wezlow */ /* polaczonych lukiem miala róny kolor. */ /* Wejscie: Liczba naturalna N>0 okreslajaca liczbe wezlow. */ /* Sekwencja par liczb A,B (0 < A,B <= N). Para taka*/ /* oznacza, ze wezly A,B sa polaczone lukiem. */ /* Wyjscie: Minimalna liczba potrzebnych kolorow */ /*Efekt ub: Brak */ /* Uwagi: Program koloruje graf metoda brutalnej sily. */ /*************************************************************/ Personal Software Process, cz. I (30) Standard kodowania powinien zawiera ustalenia odnonie do nagłówka programu. Nagłówek prezentowany na slajdzie jest moj modyfikacj nagłówka proponowanego przez Wattsa Humphrey a. Zawiera on siedem pól. Pole Program okrela nazw programu. Ta nazwa bdzie si te pojawia w rejestrach czasu i defektów. Program prezentowany na slajdzie nazywa si KolorGraf. Pole Autor podaje imi i nazwisko osoby, która napisała ten program. W tym przypadku jest to Jerzy Nawrocki. Pole Data pokazuje dat rozpoczcia prac nad kodem programu. Jak wida, prac nad kodem programu KolorGraf rozpoczto 20 maja Data opracowania ostatniej wersji programu, która te czsto jest potrzebna, bdzie dostpna automatycznie, jako data zapisania pliku z programem. Pole Funkcja zawiera moliwie krótk specyfikacj programu. Jak wida, program KolorGraf koloruje wzły podanego grafu nieskierowanego w taki sposób, aby kada para wzłów połczonych łukiem miała róny kolor. Jeli specyfikacja byłaby bardziej złoona, to mona ogólnie napisa czego program dotyczy i poda np. odwołanie do strony www zawierajcej dokładny opis problemu. W polu Wejcie umieszcza si opis danych wejciowych i ich roli w programie. W przypadku programu prezentowanego na slajdzie mamy na wejciu liczb naturaln N wiksz od zera, okrelajc liczb wzłów w grafie, a ponadto sekwencj par liczb A, B (kada z tych liczb jest wiksza od zera i nie wiksza ni N). Para taka oznacza, e wzły o numerach A, B s połczone łukiem. Pole Wyjcie opisuje dane bdce wynikiem działania programu. W naszym przypadku jest to minimalna liczba kolorów potrzebnych do pokolorowania grafu. Pole Efekt ub. zawiera opis efektu ubocznego (na przykład opis zmian w bazie danych, jakie nastpuj po wywołaniu programu). Jak wida, wykonanie programu KolorGraf nie powoduje powstania adnych efektów ubocznych, czyli jest to prosty program transformujcy dane wejciowe w dane wyjciowe. W ostatnim polu, Uwagi, umieszcza si uwagi na temat implementacji. Moe to by wskazanie algorytmu przez jego nazw (jeli jest to algorytm ogólnie znany) lub te odwołanie si np. do artykułu opisujcego dany algorytm. W przypadku programu KolorGraf zastosowano metod brutalnej siły, czyli przeglda si wszystkie moliwe pokolorowania grafu. 30

31 Standard kodowania int N; /* Liczba wezlow w grafie: 0 < N <= MaxN */ int A, B; /* Numery rozwazanych wezlow: 0 < A,B <= N */ int Kolor; /* Numer rozwazanego koloru: 0 < Kolor <= N */ int x41; int PopKG; Personal Software Process, cz. I (31) Standard kodowania powinien te okrela sposób tworzenia identyfikatorów, czyli nazw zmiennych, nazw funkcji itp. Identyfikatory powinno si tak dobiera, aby łatwo było domyli si, jak rol dany identyfikator pełni w programie. Identyfikator zadeklarowany w trzecim wierszu jest klasycznym przykładem dobrze dobranego identyfikatora. Jego nazwa, Kolor, sugeruje, e bdzie w tej zmiennej pamitany numer koloru. Ponadto mamy komentarz, który opisuje rol zmiennej Kolor wynika z niego, e faktycznie zmienna ma pamita numer rozwaanego koloru. Jest te informacja o dopuszczalnych wartociach, jakie moe przyjmowa zmienna kolor: s to liczby całkowite od 1 do N. Generalnie naley unika nazw jednoliterowych, chyba e nawizuj one do specyfikacji programu lub te wystpuj w zewntrznym opisie algorytmu (np. w artykule prezentujcym ten algorytm). Poniewa nazwy N, A i B zadeklarowane w pierwszych dwóch wierszach, wystpiły w specyfikacji programu KolorGraf, zatem mog równie wystpi w programie. Ponadto s one opisane w komentarzu i dla kadej zmiennej podano zakres wartoci, jakie moe ona przyjmowa. Zatem te deklaracje s jak najbardziej poprawne pod wzgldem metodycznym. 31

32 Standard kodowania int N; /* Liczba wezlow w grafie: 0 < N <= MaxN */ int A, B; /* Numery rozwazanych wezlow: 0 < A,B <= N */ int Kolor; /* Numer rozwazanego koloru: 0 < Kolor <= N */ int x41; int PopKG; Personal Software Process, cz. I (32) Dwa ostatnie wiersze zawieraj deklaracje identyfikatorów, jakich powinno si unika. Ich nazwy nic nie mówi. Brakuje te opisania ich roli i podania zakresu dopuszczalnych wartoci. Mona przyj zasad, e w przypadku, gdy zmienna moe przyjmowa dowolne wartoci danego typu, jako zakres dopuszczalnych wartoci wpisuje si słowo ANY (po angielsku any znaczy jakikolwiek ). 32

33 Standard kodowania while (scanf("%d %d", &A, &B)>0){ if (0<A && A<=N && 0<B && B<=N) Luk[A,B]= True; LiczbaLukow++; } Personal Software Process, cz. I (33) Standard kodowania powinien te prezentowa zasady, na jakich wprowadza si wcicia do tekstu programu. Wcicia powinny by widoczne, ale nie powinny by zbyt głbokie, bo wtedy troch mocniej zagniedone instrukcje byłyby bardzo wskie. Najczciej przyjmuje si wcicia od 3 do 5 spacji. Na slajdzie zastosowano wcicia wielkoci trzech spacji. Wane, aby wcicia w moliwie czytelny sposób oddawały zagniedanie instrukcji. 33

34 Standard kodowania while (scanf("%d %d", &A, &B)>0){ /* Czytaj kolejne pary */ /* wezlow A,B i dla kazdej,*/ if (0<A && A<=N && 0<B && B<=N) /* o ile jest poprawna, */ Luk[A,B]= True; /* zapamietaj, ze jest luk */ /* miedzy tymi wezlami. */ } Personal Software Process, cz. I (34) Kolejnym aspektem, który powinien by poruszony w standardzie kodowania jest sposób komentowania instrukcji. Panuje ogólnie akceptowany pogld, e komentarze do instrukcji powinny by tak napisane, aby pomagały czytelnikowi zrozumie kod. Rozwamy fragment kodu pokazany na slajdzie. Mona go na przykład skomentowa w sposób pokazany na slajdzie: czytaj kolejne pary wzłów A,B i dla kadej z nich, o ile jest poprawna, zapamitaj, e jest łuk midzy tymi wzłami. Komentarz niesie informacj, która nie wynika bezporednio z tego fragmentu kodu i to moe by cenn wskazówk dla osoby próbujcej zrozumie kod. 34

35 Standard kodowania while (scanf("%d %d", &A, &B)>0){ /* Czytaj kolejne pary */ /* wezlow A,B i dla kazdej,*/ if (0<A && A<=N && 0<B && B<=N) /* o ile jest poprawna, */ Luk[A,B]= True; /* zapamietaj, ze jest luk */ /* miedzy tymi wezlami. */ } while (scanf("%d %d", &A, &B)>0){ /* Jak dlugo funkcja scanf,*/ /* czytajac wartosci A,B, */ /* zwraca wartosc dodatnia,*/ if (0<A && A<=N && 0<B && B<=N) /* sprawdz, czy A,B naleza */ /* do przedzialu [1, N] i */ Luk[A,B]= True; /* zapamietaj wartosc True */ /* w tablicy Luk o wspol- */ /* rzednych A,B. */ } Personal Software Process, cz. I (35) Na dole slajdu mamy pokazany ten sam kod, ale z innym komentarzem: jak długo funkcja scanf, czytajc wartoci A,B, zwraca warto dodatni, masz sprawdzi, czy A,B nale do przedziału domknitego [1, N] i masz zapamita warto True w tablicy Luk o współrzdnych A,B. Ten komentarz w zasadzie powiela informacj zawart w kodzie, zatem raczej nie pomoe czytelnikowi zrozumie programu. Tego typu komentarzy naley unika. 35

36 Plan wykładu < < " # < " # $ < " % < < & #% < % Personal Software Process, cz. I (36) Poziom bazowy PSP obejmuje równie propozycj samodoskonalenia, któr chciałbym teraz omówi. 36

37 Uproszczony rejestr defektów % ), B C &.%/!%!#01%234,%2534% Personal Software Process, cz. I (37) Jak pamitamy, przy pracy nad programem KolorGraf pojawił si defekt zwizany z brakiem znaku & przed nazw zmiennej. Wykrycie i usunicie tego defektu kosztowało 0.5 godz. pracy. Mona uzna, e jest to wypadek przy pracy i ufa, e taka sytuacja si wicej nie powtórzy. Mona te zmodyfikowa proces tworzenia oprogramowania tak, aby radykalnie zmniejszy prawdopodobiestwo pojawienia si tego typu defektu w przyszłoci. Takie propozycje modyfikacji s propozycjami samodoskonalenia. 37

38 Propozycja samodoskonalenia ( & & % & & & # % Personal Software Process, cz. I (38) Formularz propozycji samodoskonalenia zaproponowany przez Humphrey a składa si z identyfikatora procesu i trzech głównych czci: opisu problemu (kady problem ma swój numer), opisu propozycji udoskonalenia (jej numer odpowiada numerowi opisu problemu) oraz notatek i komentarza (tutaj mog si pojawi m.in. uwagi na temat silnych stron danego procesu). 38

39 Uproszczony rejestr defektów % ), B C &.%/!%!#01%234,%2534% Personal Software Process, cz. I (39) Jeli postanowimy, e trzeba zmodyfikowa proces tak, aby problem brakujcego znaku & wicej si nie pojawił, to moemy potraktowa ten defekt jako problem wymagajcy udoskonalenia procesu. 39

40 Propozycja samodoskonalenia ( & & %!1,% % +-%#%#61%254 6%6061/%! & & & # +%+/%*0%60%!, %,8 % Personal Software Process, cz. I (40) Zatem moemy w sekcji Opis problemu umieci nastpujcy zapis: Straciłem 0.5 godziny, bo brakowało znaku & w wywołaniu funkcji scanf. Natomiast w sekcji Opis propozycji udoskonalenia moemy zapisa, e naley wprowadzi do procesu przegldy kodu i w trakcie przegldu trzeba zawsze sprawdzi, czy wszystkie wywołania funkcji scanf maj znak & przed nazw zmiennej (oczywicie znak & nie jest potrzebny, jeli zmienna zawiera wskanik ale to powinno by wiadome osobie, która bdzie dokonywała przegldu). Jak wida, problem i zwizana z nim propozycja udoskonalenia, majca na celu rozwizanie tego problemu, s powizane tym samym numerem. 40

41 Poziomy PSP Stand. kodu + Pomiar rozm. + PS Rejestry czasu i defektów 0.Bazowy Personal Software Process, cz. I (41) Omówilimy wszystkie najistotniejsze elementy zwizane z poziomem bazowym. 41

42 Plan wykładu < < " # < " # $ < " % < < & #% < % Personal Software Process, cz. I (42) Przejdziemy teraz do omówienia metody szacowania rozmiaru kodu, która jest wykorzystywana w PSP. 42

43 Model dojrzałoci w PSP Szacowanie rozmiaru + raport tst Stand. kodu + Pomiar rozm. + PPO Rejestry czasu i defektów 1.Planowania 0.Bazowy Personal Software Process, cz. I (43) Szacowanie rozmiaru kodu jest zwizane z poziomem dotyczcym planowania. 43

44 Schemat planowania begin.. end 500 LOC Personal Software Process, cz. I (44) Szacunkowy rozmiar kodu jest punktem wyjcia do szacowania pracochłonnoci, a szacunkowa pracochłonno jest punktem wyjcia do opracowania harmonogramu przedsiwzicia i ustalenia daty odbioru oprogramowania. 44

45 Metoda PROBE PROxy-Based Estimating Obiekty jako elementy zastpcze Watts Humphrey, 1995 Metoda PROBE Dane historyczne Metody statystyczne Personal Software Process, cz. I (45) W PSP wykorzystuje si metod PROBE. PROBE jest skrótem od PROxy-Based Estimating, co oznacza szacowanie bazujce na elementach zastpczych, którymi s klasy obiektów. Zatem jest to metoda zorientowana na programowanie obiektowe. Jest ona oryginaln propozycj Wattsa Humphrey a. Najogólniej mówic, w metodzie PROBE zbiera si dane dotyczce wczeniej napisanych programów (s to tzw. dane historyczne) i stosujc metody wnioskowania statystycznego opracowuje si na tej podstawie szacunkowe wartoci rozmiaru kodu i pracochłonnoci. 45

46 Planowanie przedsiwzicia Wymagania Projekt koncepcyjny Szacowanie rozmiaru Szacowanie zasobów Harmonogram Produkt Baza rozmiarów Baza produktyw. Dostpne zasoby Rozmiar, pracochł. Personal Software Process, cz. I (46) W PSP, jak w wielu innych metodykach, planowanie odbywa si na podstawie wymaga, których głównym ródłem jest klient i przyszli uytkownicy kocowi budowanego systemu. W oparciu o wymagania tworzony jest w PSP tzw. projekt koncepcyjny systemu. Projekt ten ma głównie pomóc w oszacowaniu potrzebnych zasobów. Jak ju wczeniej wspomniałem, najpierw szacuje si rozmiar kodu, jaki trzeba bdzie napisa. Wykorzystuje si do tego projekt koncepcyjny i baz danych historycznych zawierajc dane na temat rozmiarów wczeniej napisanych programów. Po oszacowaniu rozmiaru kodu szacuje si pracochłonno przedsiwzicia. To oszacowanie powstaje na podstawie szacunkowego rozmiaru kodu i bazy danych historycznych zawierajcej dane dotyczce produktywnoci (czyli szybkoci programowania). Znajc pracochłonno przedsiwzicia mona opracowa jego harmonogram. Warto przy tym wzi pod uwag dostpne zasoby. Jeli na przykład oszacowalimy, e napisanie jakiego oprogramowania zajmie 2 tygodnie, ale za tydzie jedziemy na 2-tygodniowe szkolenie do Wielkiej Brytanii, to trzeba to uwzgldni w harmonogramie przedsiwzicia. Po zaplanowaniu przedsiwzicia przechodzi si do realizacji produktu. Głównym efektem jest produkt kocowy, który powinien trafi do klienta. Ponadto naley zaktualizowa baz danych historycznych wprowadzajc dane dotyczce faktycznego rozmiaru kodu i faktycznej pracochłonnoci. 46

47 Planowanie przedsiwzicia Wymagania Projekt koncepcyjny Szacowanie rozmiaru Szacowanie zasobów Harmonogram Produkt Baza rozmiarów Baza produktyw. Dostpne zasoby Rozmiar, pracochł. Personal Software Process, cz. I (47) Metoda PROBE obejmuje projekt koncepcyjny i szacowanie rozmiaru. 47

48 Metoda PROBE Projekt koncepcyjny Identyfikuj klasy obiektów Liczba Rodzaj Rozmiar metod klasy rozmyty Oblicz nowe i zmodyfikowane LOC Oszacuj rozmiar programu Oblicz przedział ufnoci Personal Software Process, cz. I (48) Na podstawie projektu koncepcyjnego okrela si dla kadej klasy obiektów liczb jej metod, rodzaj klasy (bdzie jeszcze o tym mowa) i jej rozmiar rozmyty. Nastpnie okrela si ile linii kodu trzeba bdzie napisa (s to nowe linie kodu) a ile zmodyfikowa (z modyfikacj mamy do czynienia przy opracowywaniu kolejnej ulepszonej wersji tego samego programu). Na tej podstawie szacuje si rozmiar całego kodu, jaki trzeba bdzie napisa. W metodzie PROBE nie jest to trywialny krok w oparciu o dane dotyczce naszych wczeniejszych szacunków i faktycznych rozmiarów kodu metodami statystycznymi koryguje si zaproponowane w poprzednim kroku oszacowanie. Ale kade oszacowanie jest obarczone jakim błdem. Czasami moe to by bardzo duy błd. W metodzie PROBE okrela si przedział ufnoci dla obliczonego wczeniej rozmiaru kodu, dziki czemu mamy informacj na temat niepewnoci otrzymanego oszacowania. W trakcie tego wykładu przedstawi jedynie szacowanie rozmiaru. Obliczanie przedziału ufnoci zostanie omówione w trakcie nastpnego wykładu. 48

49 Metoda PROBE 1. Opracuj projekt koncepcyjny (klasy i metody + ich funkcje) Personal Software Process, cz. I (49) Metoda PROBE składa si z siedmiu kroków. W pierwszym kroku naley opracowa wspomniany wczeniej projekt koncepcyjny, w tym naley wyodrbni klasy i ich metody oraz opisa funkcj, jak dana klasa ma pełni w programie (opis ten nie musi by szczegółowy). 49

50 Metoda PROBE 2. Kadej klasie przypisz jej rodzaj. < <. = <! < > Drapacz chmur Kociół Gara Personal Software Process, cz. I (50) Nastpnie kadej klasie naley przypisa jej rodzaj. Chodzi o trafno szacowania rozmiaru. Jeli mielibymy zbudowa duy gara, to i tak bdzie on znacznie mniejszy ni mały drapacz chmur. Dlatego potrzebna jest informacja o rodzaju budowli, czy w naszym przypadku rodzaju klasy. Watts Humphrey proponuje m.in. nastpujce rodzaje klas: I/O S to klasy oferujce głównie operacje wejcia-wyjcia. Text Ten rodzaj klas słuy głównie do przetwarzania tekstu. Calculation S to klasy zorientowane na obliczenia o charakterze numerycznym. Data Klasy tego rodzaju s abstrakcyjnymi typami danych (np. kolejka, słownik itp.). 50

51 Metoda PROBE 2. Kadej klasie przypisz jej rodzaj. < <. = <! < > < ; Drapacz chmur Kociół Gara Personal Software Process, cz. I (51) Niestety, kwestia podziału klas na rodzaje została nader pobienie potraktowana przez Wattsa Humphrey a (Humphrey wprowadził jeszcze dwa dodatkowe rodzaje, Logic i Set-up, ale nie wyjanił co jest cech charakterystyczn klas tego rodzaju). By moe warto byłoby wprowadzi klas Others na wypadek, gdyby jaka klasa z modelu koncepcyjnego nie pasowała do adnego ze wspomnianych rodzajów. 51

52 Metoda PROBE 3. Oszacuj rozmyty rozmiar kadej klasy. Bardzo duy Duy redni Mały Bardzo mały Personal Software Process, cz. I (52) W trzecim kroku naley oszacowa rozmyty rozmiar kadej klasy. Rozmiar rozmyty oznacza rozmiar scharakteryzowany słowami. Mona na przykład, tak jak to pokazano na slajdzie, przyj skal 5-stopniow: bardzo duy, duy, redni, mały i bardzo mały. Mona te zdecydowa si na skale 3-stopniow. Wane, by przez cały czas mała klasa rodzaju Calculation oznaczała klasy o mniej-wicej podobnym rednim rozmiarze metody. Z tego wzgldu lepiej jest na pocztku przyj skal 3- stopniow i ewentualnie w przyszłoci j rozbudowa. 52

53 Metoda PROBE 4. Znajc: jzyk programowania rodzaj klasy rozmyty rozmiar klasy liczb metod oszacuj, korzystajc z danych historycznych, rozmiar kadej klasy. Personal Software Process, cz. I (53) W czwartym kroku, znajc jzyk programowania, jaki zostanie uyty, rodzaj klasy wystpujcej w modelu koncepcyjnym, rozmyty rozmiar klasy oraz szacowan liczb metod, naley oszacowa, w oparciu o dane historyczne, rozmiar kadej klasy. 53

54 Metoda PROBE = 5 5. Okrel pocztkowe oszacowanie rozmiaru kodu, X, dodajc wartoci otrzymane w poprzednim kroku. Personal Software Process, cz. I (54) Pocztkowe oszacowanie rozmiaru kodu, oznaczane przez X, otrzymujemy dodajc wartoci otrzymane w poprzednim kroku. 54

55 Metoda PROBE 5, czyli Zastosuj regresj liniow, aby otrzyma szacowany rozmiar programu, Y. β 1 = x i y i - n x avg y avg x i2 - n x avg 2 β 0 = y avg - β 1 x avg Personal Software Process, cz. I (55) Niestety, bardzo czsto programici maj tendencj do nadmiernego optymizmu i na etapie planowania wszystko wydaje im si prostsze i łatwiejsze ni to ma miejsce w rzeczywistoci. Dlatego te szacunkowy rozmiar kodu, X, otrzymany w poprzednim kroku naley skorygowa. W metodzie PROBE stosuje si metod regresji liniowej. Na podstawie danych historycznych opisujcych szacunkowy i faktyczny rozmiar kodu wyznacza si wartoci współczynników regresji liniowej, 0 i 1, w sposób pokazany na slajdzie. 55

56 Metoda PROBE 5, czyli Zastosuj regresj liniow, aby otrzyma szacowany rozmiar programu, Y. Y = β 1 X + β 0 β 1 = x i y i - n x avg y avg x i2 - n x avg 2 β 0 = y avg - β 1 x avg Personal Software Process, cz. I (56) n oznacza liczb programów w bazie danych historycznych. xi oraz yi oznaczaj odpowiednio szacowany i faktyczny rozmiar i-tego programu. Natomiast xavg oraz yavg podajredni warto szacunkowego i faktycznego rozmiaru kodu dla wszystkich n programów. Szacowany rozmiar programu, Y, oblicza si mnoc warto X przez 1 i dodajc 0. 56

57 Metoda PROBE Dla 100% przedział wynosi [0; + ]. 7. Korzystajc z rozkładu t Studenta i odchylenia standardowego oblicz przedział dla podanego poziomu ufnoci. Personal Software Process, cz. I (57) W ostatnim kroku, korzystajc z rozkładu t Studenta i odchylenia standardowego od prostej regresji, oblicza si przedział ufnoci dla podanego poziomu ufnoci. Ten krok zostanie omówiony w trakcie nastpnego wykładu. 57

58 Przykład szacowania rozmiaru kodu " # )?, 6 6> ) 6 54!G = 4;. H 8 > 6 B IHC BHIC BI HC H H JJJ H 5 J H 5 J HG Personal Software Process, cz. I (58) Na zakoczenie przedstawi przykład szacowania rozmiaru kodu. Załómy, e mamy w swoim dorobku cztery programy napisane w jzyku C++. Z ich analizy wynika, e metody zawarte w klasach rodzaju Calculation maj od 4 do 49 linii kodu ródłowego, dla klas rodzaju Data ten przedział wynosi od 4 do 32 linii kodu, metody klas I/O zajmuj od 8 do 27 linii kodu, za metody klas rodzaju Text maj od 6 do 94 linii kodu. Załómy, e bdziemy posługiwa si 3-stopniow skal oceny rozmiaru klasy: mała, rednia i dua. Na podstawie zebranych danych wyznaczymy wartoci numeryczne odpowiadajce małym, rednim i duym klasom poszczególnych rodzajów. Przyjmijmy, e mała klasa ma metody od Min do x, rednia od x do y, natomiast dua od y do Max. Jeli załoymy, e wartoci numeryczne odpowiadajce poszczególnym rozmiarom rozmytym tworz postp geometryczny, to stosunek górnej granicy kadego przedziału do dolnej granicy powinien by taki sam, czyli prawdziwa jest równo pokazana na slajdzie. Oznaczmy ten iloraz liter k. Z równoci tych wynika, e k do potgi trzeciej jest równe ilorazowi Max i Min. Zatem k mona obliczy, jako pierwiastek trzeciego stopnia z ilorazu Max do Min. 58

59 Przykład szacowania rozmiaru kodu " # )?, 6 6> 45 ) !G = 4; 27. H 8 > 6 47 B IHC BHIC BI HC H H JJJ H 5 J H 5 J HG Personal Software Process, cz. I (59) Do tabeli wpisano wartoci k obliczone na podstawie tego wzoru. 59

60 Przykład szacowania rozmiaru kodu " #, )!G. H 6 6 = 8 H 6> 54 4; > )? B IHC J KH H J HJK J K Personal Software Process, cz. I (60) Obliczymy teraz warto numeryczn reprezentujc rozmiar metody małej klasy. Poniewa załoylimy, e granice przedziałów Min, x, y i Max tworz postp geometryczny, zatem warto numeryczna reprezentujc przedział małych klas powinna by liczona jako rednia geometryczna, czyli jako pierwiastek kwadratowy z granic przedziału. Poniewa, jak ju wczeniej si zgodzilimy, stosunek x do Min jest równy k, zatem x jest równe iloczynowi k i Min. Podstawiajc x do pierwszej równoci dostajemy wzór na warto numeryczn reprezentujc rozmiar metody małej klasy: jest to iloczyn minimalnego rozmiaru metody, Min, i pierwiastka z ilorazu k. 60

61 Przykład szacowania rozmiaru kodu " # )?, 6 6> ) ;!G = 4; 27 > =. H 8 > 6 47 > 7 J K Personal Software Process, cz. I (61) W tabeli pokazane s wartoci numeryczne dla poszczególnych rodzajów klas obliczone na podstawie tego wzoru. 61

62 Przykład szacowania rozmiaru kodu " # )?, 6 6> ) ; 225!G = 4; 27 > = 26;. H 8 > 6 47 > 7 J K Personal Software Process, cz. I (62) Poniewa granice przedziałów zwizanych z wartociami rozmytymi tworz postp geometryczny i wartoci numeryczne reprezentujce przedziały s obliczane na podstawie redniej geometrycznej granic przedziałów, zatem wartoci numeryczne reprezentujce przedziały te musz tworzy postp geometryczny. Oznacza to, e aby otrzyma wartoci numeryczne reprezentujce redniej wielkoci klasy wystarczy pomnoy wartoci dotyczce małych klas przez iloraz k. Otrzymamy wówczas wartoci numeryczne pokazane w przedostatniej kolumnie tabeli. 62

63 Przykład szacowania rozmiaru kodu " # )?, 6 6> ) ; !G = 4; 27 > = 26; 443. H 8 > 6 47 > 7 45; 7 > 5 )?J@ K Personal Software Process, cz. I (63) W podobny sposób oblicza si wartoci numeryczne reprezentujce due klasy. 63

64 Przykład szacowania rozmiaru kodu " #, )!G. H 6 6 = 8 H 6> 54 4; > ; > = > ; 45; )? > 5 H F H L L β 2 J H 4 F H 4 L 2 4 H 633 = β 3 J L F β 2 H L Personal Software Process, cz. I (64) Druga cz naszych danych historycznych dotyczy rozmiarów kodu. Mamy dane dotyczce czterech programów. W kolumnie xi znajduj si szacunkowe rozmiary kodu podane przez programist, natomiast w kolumnie yi mamy faktyczne rozmiary kodu. Dane te wykorzystamy do obliczenia współczynników regresji liniowej 0 i 1. 64

65 Przykład szacowania rozmiaru kodu " #, )!G. H 6 6 = 8 H 6> 54 4; > ; > = > ; 45; )? > 5 H F H L L β 2 J H 4 F H 4 L 2 4 H 633 = β 3 J L F β 2 H L Personal Software Process, cz. I (65) Jak wida, liczba programów, n, jest równa 4. 65

66 Przykład szacowania rozmiaru kodu H F H L L β 2 J H 4 F H 4 L β 3 J L F β 2 H L " #, )!G. H )? 6 6> ; = 4; 27 > = 26; > 6 47 > 7 45; 7 > 5 H = = Personal Software Process, cz. I (66) rednia warto oszacowa programisty wynosi 800, natomiast rednia warto faktycznego rozmiaru kodu jest równa

67 Przykład szacowania rozmiaru kodu H F H L L β 2 J H 4 F H 4 L β 3 J L F β 2 H L " #, )!G. H )? 6 6> ; = 4; 27 > = 26; > 6 47 > 7 45; 7 > 5 H H K = == = ==3333 Personal Software Process, cz. I (67) Suma iloczynów szacowanych i faktycznych rozmiarów kodu wynosi tys. 67

68 Przykład szacowania rozmiaru kodu H F H L L β 2 J H 4 F H 4 L β 3 J L F β 2 H L " #, )!G. H )? 6 6> ; = 4; 27 > = 26; > 6 47 > 7 45; 7 > 5 H H K H KH = == = ==3333 4=33333 Personal Software Process, cz. I (68) Natomiast suma kwadratów szacunkowych rozmiarów kodu wynosi tys. 68

69 Przykład szacowania rozmiaru kodu β 2 J 27 β 3 J L F β 2 H L " #, )!G. H )? 6 6> ; = 4; 27 > = 26; > 6 47 > 7 45; 7 > 5 H H K H KH = == = ==3333 4=33333 Personal Software Process, cz. I (69) Podstawiajc te wartoci do wzoru na 1 dostajemy 1,5. 69

70 Przykład szacowania rozmiaru kodu β 2 J 27 β 3 J M 233 " #, )!G. H )? 6 6> ; = 4; 27 > = 26; > 6 47 > 7 45; 7 > 5 H H K H KH = == = ==3333 4=33333 Personal Software Process, cz. I (70) Zatem 0 jest równe Współczynniki te wykorzystamy przy szacowaniu rozmiaru kodu. Podsumowujc t cz oblicze mona powiedzie, e to, czego potrzebujemy z danych historycznych obejmuje numeryczne reprezentacje wartoci rozmytych oraz współczynniki regresji liniowej 0 i 1. Pozostałe dane nie bd ju nam potrzebne. 70

71 Przykład szacowania rozmiaru kodu " #, )!G. H 82 7 ; > = > 7 β 2 J 27 β 3 J M ; 45; )? > 5 Personal Software Process, cz. I (71) Po lewej stronie slajdu mamy wszystkie dane historyczne, które bd nam potrzebne do obliczenia szacunkowego rozmiaru kodu. Jestemy gotowi do wykonania oblicze zgodnie z metod PROBE. 71

72 Przykład szacowania rozmiaru kodu N )3 " )? 9, )!G 7 ; > = ; Zaawansowana inynieria oprogramowania Metoda PROBE. H > 7 45; 7 > 5 β 2 J 27 β 3 J M Opracuj projekt koncepcyjny (klasy i metody + ich funkcje) Personal Software Process, cz. I (114) Personal Software Process, cz. I (72) Jak pamitamy, w pierwszym kroku naley opracowa projekt koncepcyjny, z którego powinno wynika, jakie bd klasy, jakie metody bd one zawierały i co te klasy maj robi. Załómy, e w naszym programie bd trzy klasy: Matrix Bdzie udostpnia podstawowe operacje zwizane z abstrakcyjn struktur danych, jak jest macierz. Linear Bdzie wykonywa operacje zwizane z algebr liniow. Linked Bdzie to klasa udostpniajca operacje na listach 2-kierunkowych. Dla uproszczenia przyjmiemy, e kada z tych klas bdzie miała po 10 metod. 72

73 Przykład szacowania rozmiaru kodu N )3 " # : " % ;+ " )? 9 *! :/, : :/ )!G. H 7 ; > = > ; 45; > 5 Zaawansowana inynieria oprogramowania Metoda PROBE 3. Oszacuj rozmyty rozmiar kadej klasy. β 2 J 27 β 3 J M 233 Bardzo duy Duy redni Mały Bardzo mały Personal Software Process, cz. I (119) Personal Software Process, cz. I (73) W drugim kroku naley kadej klasie przypisa jej rodzaj. Na podstawie wczeniej przedstawionego opisu mona przyj, e klasy Matrix i Linked bd rodzaju Data, natomiast klasa Linear bdzie rodzaju Calculation. W trzecim kroku naley przypisa kadej klasie jej rozmiar rozmyty. Korzystajc ze swojego dowiadczenia i intuicji programista przyjł, e klasa Matrix bdzie miała metody redniej wielkoci, natomiast klasy Linear i Linked bd due. 73

74 Przykład szacowania rozmiaru kodu N " # " % )3 : ;+ " )? 9 *! :/, : :/ )!G 7 ; > = ; Zaawansowana inynieria oprogramowania Metoda PROBE. H > 7 β 2 J 27 β 3 J M ; 7 > 5 4. Znajc: jzyk programowania rodzaj klasy rozmyty rozmiar klasy liczb metod oszacuj, korzystajc z danych historycznych, rozmiar kadej klasy. Personal Software Process, cz. I (120) Personal Software Process, cz. I (74) W czwartym kroku naley, korzystajc z danych historycznych, oszacowa rozmiar kadej klasy, biorc pod uwag liczb jej metod. Wczeniej przyjlimy, e kada klasa bdzie miała 10 metod. 74