Koncepcja wyk adu: Jerzy Nawrocki/Łukasz Olekwazniak.mimuw.edu.pl/images/d/db/Io-12-wyk-color.pdf · Kontrola jakości artefaktów Język UML, cz. I Język UML, cz. II Metody formalne

1

Inżynieria oprogramowania

Programowanie Ekstemalne

Koncepcja wykładu:Slajdy/Lektor/Montaż:

Jerzy Nawrocki/Łukasz OlekŁukasz Olek

Witam Państwa serdeczenie na kolejnym wykładzie dotyczącym inżynieriioprogramowania!

2


Programowanie Ekstremalne (2)

Plan wykładów

Zasady skutecznego działaniaSpecyfikacja wymagańKontrola jakości artefaktówJęzyk UML, cz. IJęzyk UML, cz. IIMetody formalneWzorce projektoweZarządzanie konfiguracjąWprowadzenie do testowaniaAutomatyzacja wykonywania testówProgramowanie EkstremalneEwolucja oprogramowania i refaktoryzacja

Jest to jedenasty wykład w tym cyklu i będzie dotyczył podejść do projektówinformatycznych, a w szczególności Programowania Ekstremalnego.Zaczniemy od krótkiego wprowadzenia…

3



Wprowadzenie

• Syndrom LOOP– Late

Późno– Over budget

Przekrocznoy budżet– Overtime

Nadgodziny– Poor quality

Kiepska jakość

LOOP

W dziedzinie tworzenia oprogramowania, w latach 80-90 nasilił się syndromLOOP. Powstające oprogramowanie stawało się coraz bardziej złożone, aludzie nie mieli sposobu na poradzenie sobie z tą złożonością. W związku ztym powszechne stawało się przekraczanie terminów, nadwyrężanie budżetu,programiści wypracowywali wiele nadgodzin, a w rezultacie system miałniższą jakość.

4



Rozwiązanie problemu (lata 80-90)

Więcej dyscypliny!

Odpowiedzią na te problemy były standardy i wymagania dotyczące procesówwytwarzania oprogramowania. Wszystkie one zakładały, że należy stworzyćprocedury wykonywania poszczególnych czynności w projektachinformatycznych, a następnie zmusić programistów do ich przestrzegania.

5



ISO 9000

Audytor

Jednym z najbardziej znanych standardów dotyczących jakości (nie tylko wprojektach informatycznych) jest standard ISO 9000. Pierwsza wersja tegostandardu powstała już w 1987 roku, kolejne w 1994 i 2000.Standard ten wymagał, aby firma udokumentowała wszystkie swoje proceduryzwiązane z wytwarzaniem oprogramowania. Następnie specjalny audytorsprawdzał te procedury i firma otrzymywała certyfikat ISO 9000. Dojrzałośćfirmy badano jedynie przez pryzmat tych zdefiniowanych procedur i jeżeli firmatakowych nie posiadała była uważana za gorszą, mimo że mogła produkowaćświetne oprogramowanie.

6



Model CMM (Capability Maturity Model)

• Departament Obrony USA• SEI, Carnegie-Mellon

Univ.• 1987-97• CMMI: grudzień, 2000

CMM

Innym sposobem na ocenę procesów wytwarzania oprogramowania wprzedsiębiorstwie jest model dojrzałości CMM, opracowany przez SoftwareEngineering Institute z Carnegie-Mellon University.Model był rozwijany w latach 1987-1997. Od 1997 roku zaczęto pracować nadnowszą wersją nazwaną CMMI, która była pozbawiona wielu wad modeluCMM.Model CMM dzieli firmy na 5 poziomów, w zależności od ich potencjalnychmożliwości wyprodukowania oprogramowania wysokiej jakości. Z każdympoziomem związany jest zbiór standardów (procedur), które muszą byćprzestrzegane w firmie.

Poziom pierwszy - nie nakłada żadnych wymagań. Każda firma wytwarzającaoprogramowanie znajduje się początkowo na tym poziomie.

7



Procedury dla CMM Poziom 2

• przeglądy zobowiązań zewnętrznych• opracowywanie planu przedsięwzięcia• szacowanie rozmiaru, pracochłonności,

kosztu, krytycznych zasobówobliczeniowych i harmonogramu

• dokonywanie zmian w planie• przeglądy przedsięwzięcia przy

kamieniach milowych• planowanie zapewnienia jakości• ...

Pomiędzy poziomem pierwszym, a drugim obserwujemy ogromną różnicę.Poziom pierwszy nie nakłada żadnych wymagań, natomiast na poziomiedrugim należy mieć opracowane dosyć dojrzałe procesy wytwórcze.Wybrane procedury dla poziomu 2 przedstawione są na slajdzie. Dotyczą onepodstaw zarządzania projektem, w celu śledzenia kosztu i harmonogramu.Przy każdym kamieniu milowym następuje zbadanie postępów projektu.

8



Krytyka podejść zorientowanych na dyscyplinę

• Dużo czasu poświęcanegona administrację

• Papierowa fikcja• Skupienie się na procesie,

nie jakości produktu• Zapis procedur utrudnia

poprawy procesów

Niestety, podejścia zorientowane na procedury i dyscyplinę mają poważnewady. Niektórzy zarzucają, iż dużo czasu trzeba poświęcić na administrację,zamiast na pisanie oprogramowania.Inni mówią o papierowej fikcji - dokumenty często powstają sztucznie, tylkodlatego, że są wymagane, ale nic z nich nie wynika.Kolejny argument to opinia, iż nie zawsze skupienie się na jakości procesuskutkuje wysoką jakością produktu.Jedną z największych wad jednak są sztywne procedury. Po opracowaniuprocedur i otrzymaniu certyfikatu (kosztownego zresztą) nie można dowolnieich zmieniać, nawet wtedy, gdy zmiana ta skutkowałaby oczywistą poprawąprocesu. Po każdej zmianie wymagany jest ponowny audyt, na co niewszystkie organizacje stać.

9



Dyscyplina zabija inicjatywę i elastyczność

Ostatni argument przeciwko zorientowaniu na dyscyplinę - opracowaneprocedury zabijają inicjatywę i elastyczność.Dobrze obrazuje to rysunek na slajdzie.Podsumowując… W podejściu zorientowanym na procedury i dyscyplinęstarano się poprawić jakość wytwarzanego oprogramowania. Niestetypoprawiając jedną rzecz, zaniedbano inną, jaką jest fakt, iż praca programistyto praca twórca. Tego rodzaju pracy nie można dobrze opisać za pomocązbioru procedur, a następnie rygorystycznie ich przestrzegać.

10



Programowanie Ekstremalne

• Extreme Programming (XP):– lekka (ang. agile)

metodyka rozwojuoprogramowania

– 1999– Kent Beck

Dlatego też, pod koniec lat 90-tych zaczęto obserwować irytację podejściaminastawionymi na kontrolowanie procedur i dyscyplinę. Ludzie zastanawiali się,w jaki sposób można „odchudzić” procesy wytwarzania oprogramowania, przyzachowaniu wysokiej jakości (lub czasem wręcz jej poprawieniu). W tensposób powstały „lekkie” metodyki rozwoju oprogramowania, których dobrymprzykładem jest Programowanie Ekstremalne, po angielsku zwane również„XP”. XP zostało wymyślone przez Kenta Becka w latach 1996-1999, kiedy topracował w firmie Chrysler nad oprogramowaniem przetwarzającym listy płacdla 87000 pracowników.

11



Plan wykładu

• Wprowadzenie• Manifest zwinności• Wartości XP• Główne reguły i praktyki

XP:– Struktura zespołu– Relacje z klientem– Zapewnienie jakości– Programowanie parami

• Czynniki ryzyka

Po tym krótkim wprowadzeniu zostaną przedstawione następujące tematy:-manifest zwinności - zbiór zasad wspólny dla wszystkich zwinnych metodykwytwarzania oprogramowania (nie tylko XP)-wartości, którymi kieruje się Programowanie Ekstremalne-główne reguły i praktyki XP, dotyczące struktury zespołu, relacji z klientem,zapewnienia jakości, czy też programowania parami-czynniki ryzyka, czy też wady programowania ekstremalnego

12



Manifest zwinności

• Luty 2001, Snowbird,Utah, 17 osób:– Kent Beck

– Alistair Cockburn

– Martin Fowler

– Jim Highsmith

W 2001 roku w kurorcie narciarskim Snowbird w stanie Utah w USA spotkałosię 17 osób związanych ze zwinnymi metodykami.Ważniejsze osobistości to:-wspomniany już Kent Beck - twórca metody kart CRC stosowanej podczasanalizy obiektowej, autor narzędzi xUnit - wspomagających testowaniejednostkowe oraz twórca XP-Alistair Cockburn - autor rodziny zwinnych metodyk Crystal, oraz książekpoświęconych inżynierii wymagań (głównie przypadkom użycia)-Martin Fowler - twórca pomysłu refaktoryzacji, autor świetnej książki „UMLDistilled” (UML w kropelce)-Jim Highsmith - autor metodyki Adaptive Software DevelopmentOsoby te miały już pewne doświadczenia związane ze zwinnymi metodykamiwytwarzania oprogramowania, a spotkały się w celu przedyskutowaniawspólnych zasad tych metodyk.

13



Manifest zwinności

Jednostki i interakcje

O K

Działające oprogr.

Współpraca klienta Nadążanie za zmianami

Jutro, albo nigdy!

W wyniku tego spotkania powstał tzw. manifest zwinności, czyli zbiór 4podstawowych zasad zwinnych metodyk wytwarzania oprogramowania.Postulują oni, iż ważniejsze:

•Jednostki i interakcje niż procesy inarzędzia, czyli ewidentnie sprzeciwiająsię podejściom zorientowanym naprocedury i dyscyplinę

•Działające oprogramowanie niżobszerna dokumentacja - stawiają najakość produktu końcowego•Współpraca klienta niż negocjacjakontraktu•Nadążanie za zmianami niżtrzymanie się planu - to ostatniazasada i zarazem kolosalna zmianaw porównaniu do podejśćzorientowanych na dyscyplinę. Odtej chwili dowolnie dopuszczamyzmiany w wymaganiach, zamiastblokować je i tłumaczyć tym, że „jużza późno”, ale zakładamyjednocześnie, że klient za wszystkozapłaci.

14



Plan wykładu



• Czynniki ryzyka

Przejdźmy do wartości XP. XP wymienia pięć wartości (początkowo były 4,jedna została dodana w drugim wydaniu książki Kenta Becka), na którychzbudowana jest metodyka. Zobaczmy, co to za wartości…

15



Wartości XP

• Komunikacja– wymagania, wyobrażenie systemu– głównie werbalna

• Prostota• Sprzężenie zwrotne• Odwaga• Szacunek

Są to po kolei: komunikacja, prostota, sprzężenie zwrotne, odwaga, szacunek.Jak widać, są one bardzo ogólne, można by powiedzieć, że aż dziwne, żedotyczą one podejścia do wytwarzania systemów informatycznych. Kent Beckstawia jednak bardzo mocno na dobre relacje pomiędzy firmą informatyczną, aklientem, stara się zbudować atmosferę zaufania - wtedy dużo łatwiej sięporozumieć, zwłaszcza w sprawach spornych.Tak więc po kolei…Pierwszą wartością XP jest komunikacja. Budowanie systemówinformatycznych wymaga przekazania wymagań od klienta do programistów.W tradycyjnych metodykach wykorzystuje się w tym celu dokumenty(specyfikację wymagań). XP posługuje się komunikacją werbalną, dziękiczemu wiedza o systemie bardzo szybko rozprzestrzenia się w zespole. Dziękikomunikacji wszyscy członkowie zespołu mają takie samo wyobrażenieprzyszłego systemu i wiedzą w jakim kierunku projekt dąży.

16



Wartości XP

• Komunikacja• Prostota

– na początku najprostszerozwiązanie

– refaktoryzacja pomaga przekształcić wbardziej skomplikowane

• Sprzężenie zwrotne• Odwaga• Szacunek

Drugą wartością jest prostota.XP zachęca do rozpoczęcia najprostszym możliwym rozwiązaniem problemu(minimalnym, spełniającym pewne początkowe wymagania). Dopiero kiedy sięupewnimy że idziemy w prawidłowym kierunku, na tej podstawiedobudowujemy resztę.Ktoś z Państwa zaraz zacznie się buntować - przecież w momencie kiedy takeksperymentujemy i budujemy stopniowo wielu rzeczy nie będziemy w stanieprzewidzieć na początku, natomiast kiedy trzeba będzie je zrobić, okaże sięże musimy „łatać” obecne rozwiązanie. W ten sposób w bardzo krótkim czasiearchitektura systemu może się popsuć, a jakoś znacznie spadnie.XP radzi sobie z tym problemem za pomocą refaktoryzacji. Refaktoryzacja, tometoda poprawiania architektury obecnego rozwiązania za pomocą małychprzekształceń, zamiast tworzenia wszystkiego od nowa. Tak więc dziękirefaktoryzacji jakość produktu jest stale na najwyższym poziomie.Dzięki prostocie programiści skupiają się na projektowaniu i kodowaniu napotrzeby bieżącego dnia, a nie robią nic na wyrost.Ta wartość jest powiązana z „komunikacją”, gdyż prostota architektury i koduułatwia zrozumienie, przez co komunikacja staje się łatwiejsza.

17



Wartości XP

• Komunikacja• Prostota• Sprzężenie zwrotne

– w różnych wymiarach:• system• klient• zespół

• Odwaga• Szacunek

Kolejna wartość to sprzężenie zwrotne.W programowaniu ekstremalnym sprzężenie zwrotne dotyczy różnychwymiarów:-systemu - ważna jest odpowiedź systemu, otrzymywana w procesietestowania jednostkowego. Dzięki testom programiści mogą bardzo szybkosprawdzić poprawność odpowiedzi systemu w momencie wprowadzaniazmian.-klienta - w postaci testów akceptacyjnych. Klient przygotowuje takie testywraz z testerem, gdyż sam nie ma niezbędnej wiedzy informatycznej. Dziękitakim testom można sprawdzić w jakim stanie znajduje się aktualniebudowany system-zespołu - w momencie kiedy klient proponuje nowe wymagania podczas gryplanistycznej, zespół podaje szacunki ile czasu zajmie ichzaimplementowanie. Dzięki temu klient może podjąć decyzję, czy danewymaganie będzie realizowane od razu, w przyszłości, a może w ogóle.

18



Wartości XP

• Komunikacja• Prostota• Sprzężenie zwrotne• Odwaga:

– aby nie projektować na wyrost– aby refaktoryzować kod– aby wyrzucić kod kiedy potrzeba

• Szacunek

Odwaga jest również postrzegana w wielu wymiarach.Po pierwsze, odwaga jest potrzebna, aby przestrzegać zasady projektowania ikodowania wg aktualnych potrzeb, bez zastanawiania się co będzie potrzebnew przyszłości.Po drugie, odwaga, aby nie angażować się za bardzo w projektowanie i odrazu przejść do kodowania.Po trzecie, odwaga jest potrzebna, aby zrefaktoryzować kod, wtedy kiedy tojest potrzebne, aby nie bać się refaktoryzacji.Po czwarte, jeżeli okaże się, że pewien fragment kodu jest już nieprzydatny,lub musi zostać zmieniony, do podjęcia decyzji o wyrzuceniu takiego kodupotrzeba dużo odwagi

19



Wartości XP

• Komunikacja• Prostota• Sprzężenie zwrotne• Odwaga• Szacunek

– pomiędzy członkami zespołu– czasu i pracy innych

Ostatnia wartość to szacunek. Szacunek do pracy i czasu innych osób wzespole:-nie można wysyłać do repozytorium zmian, które nie dają się skompilowaćlub powodują błędy w testach jednostkowych, gdyż przez to praca innychosób będzie utrudniona, lub niemożliwa i stracą one dużo czasu.-poprzez dążenie do najwyższej jakości i szukanie najlepszych rozwiązańprojektowych (dzięki refaktoryzacji). Dzięki temu innym osobom będzie dużołatwiej wykorzystać kod napisany przez nas.

20



Wartości XP

Podsumujmy. Najważniejsze wartości XP to: komunikacja, prostota,sprzężenie zwrotne, odwaga, szacunek.Zauważmy, że w odróżnieniu od podejść zorientowanych na dyscyplinę, niema tutaj mowy o procesach, dokumentacji, narzędziach. Najważniejsi sąludzie, gdyż to oni tworzą rozwiązania informatyczne.

21



Plan wykładu



• Czynniki ryzyka

Przejdźmy do szczegółów metodyki programowania ekstremalnego. Po koleizapoznamy się z jej regułami…Najpierw omówimy strukturę zespołu XP.

22



Struktura zespołu

Klient

Programiści

Coach

Tracker

Tester

XP wymienia 2 najważniejsze role osób z zespołu:-programiści-klient.Zauważmy, że klient uważany jest za członka zespołu, więc musi przez całyczas pracować razem z informatykami (w jednym pomieszczeniu). Czasemnie występuje w tej roli osobiście, lecz za pośrednictwem przedstawicielaklienta.Oprócz tego mamy jeszcze kilka ról pomocniczych:-tester, którego zadaniem jest napisanie skryptów testowych na podstawierozmów z klientem-coach, to osoba, która pomaga rozwiązywać napotkane problemy-tracker natomiast zbiera statystyki dotyczące wykonanych zadań, czasupracy i tworzy podsumowania postępów projektu

23



Plan wykładu



• Czynniki ryzyka

XP bardzo mocno stawia na współpracę zespołu z klientem. Zakłada pełnezaufanie członków zespołu do klienta, oraz klienta do członków zespołu.

24



Opowieści użytkowników (ang. user stories)

Data: 06.06.2006 Typ: Nowa: X Naprawa:__ Rozbudowa:__

Numer opowieści: 23

OPOWIEŚĆ: System przechowuje artykuły w formaciePDF. Umożliwia ich dodawanie, listowanie, atakże pobieranie.

Rozmiar: 3 dni

Po pierwsze - przedstawiciel klienta jest ciągłym źródłem wymagań.Wymagania są przedyskutowywane z nim na bieżąco, natomiast ślad z tychdyskusji jest przechowywany w formie opowieści użytkowników.Każda opowieść jest zapisana w kilku zdaniach na małej kartce papieru. Możebyć oznaczona dodatkowymi atrybutami (np. data utworzenia, typ, numer,rozmiar).

25



Opowieści użytkowników

• Są wstępem dorozmowy

• Są krótkie• Opisują funkcję/cechę

systemu• Mają wartość dla klienta• Muszą być testowalne

Muszęnapisać

opowieść

Klient

Opowieść użytkownika nie jest kompletnym wymaganiem - wymaganiabowiem są jedynie przekazywane w bezpośredniej rozmowie.Po co więc zapisywać opowieści użytkownika? Powodów jest kilka:-dzięki temu można uporządkować rozmowę o wymaganiach-łatwo przydzielać funkcje do poszczególnych przyrostów-w łatwy sposób można śledzić postęp projektuWażne, aby każda opowieść miała wartość dla klienta i była testowalna!

26



Hydrodynamiczny model projektu

Data dostarczenia Koszt Defekty Niekompletność

Jest jedna bardzo ważna prawidłowość wszystkich projektów informatycznych.Aby dobrze zrozumieć podejście programowania ekstremalnego, musimy tąprawidłowość poznać. Dobrze ją obrazuje „Hydrodynamiczny model projektu”.Istotne jest, aby każdy klient oraz informatyk znał ten model podczas rozmówo wymaganiach systemu. Bez niego może bowiem dojść do wielunieporozumień i problemów.Projekt informatyczny można zobrazować jako szczelny systemhydrodynamiczny 4 zmiennych: daty dostarczenia, kosztu, defektów orazniekompletności funkcji.

27





Z fizycznego punktu widzenia niemożliwe jest obniżenie wszystkich czterechzmiennych jednocześnie, gdyż ilość „cieczy”, czyli pracy do wykonania jeststała w projekcie informatycznym.

28





W momencie kiedy chcemy obniżyć koszt projektu, na pewno wzrośnie namjedna z innych zmiennych, np. niekompletność.Znając tę prawidłowość możemy „sterować” projektem. Np. zwiększyć jakość(obniżyć poziom defektów) poprzez zwiększenie kosztu, lub przy zachowanymkoszcie - zrezygnować z niektórych funkcji.Prawidłowość ta jest wykorzystywana w XP: zakładamy niski poziomdefektów, a klient sam steruje kosztami w zależności od tego ilefunkcjonalności sobie życzy.

29



Cykl życia: model kaskadowy i XP

Kompletnawersja

zbieranie wymagań, analiza, projektowanie, kodowanie, testowanie,…

Kolejny element Programowania Ekstremalnego to cykl życia projektu.W tradycyjnym modelu kaskadowym wytwarzania oprogramowania, napoczątku mamy rozległą fazę zbierania wymagań, analizy, projektowania,kodowania, a na końcu testowania - zanim klient otrzyma kompletną wersjęsystemu.

30




Wizja klienta

zbieranie wymagań, analiza, projektowanie, kodowanie, testowanie,… Końcowysystem

Niestety, w takim podejściu często okazuje się, że gdzieś w początkowychfazach nie zrozumieliśmy się do końca z klientem i wymagania były błędne. Wzwiązku z tym końcowy system może się zupełnie rozminąć z potrzebamiklienta.

31




Wstępnawersja

Wizjaklienta

Kolejnawersja

Wizjaklienta

Programowanie Ekstremalne stara się zaradzić temu problemowi poprzezczęste wydania systemu, czyli zbudowanie wersji, która jest pokazywanaklientowi (a często nawet wdrażana). Dzięki temu klient jest w stanieskonfrontować rezultat ze swoimi oczekiwaniami. W ten sposób kolejne wersjesystemu są coraz bliższe wizji klienta.

32



Cykl życia w XP

Wydanie 2Wydanie 1

Przyrost 1 Przyrost 2 Przyrost 1 Przyrost 2

Cykl życia w XP wygląda zatem następująco: mamy wydania podzielone naprzyrosty.

33



Pierwsze wydaniesterowca gotowe!

Stosuj częste, krótkie wydania

• Wydanie:– Ma wartość użytkową.– Trafia do użytkowników

końcowych.

Każde wydanie ma wartość użytkową i trafia do użytkowników końcowych,dzięki czemu programiści dostają sprzężenie zwrotne.

34



Przyrost I

Przyrost II

Wydanie podziel na przyrosty

• Przyrost:– Niepusty zbiór opowieści

użytkownika.– Charakter wewnętrzny

(nie trafia doużytkownikakońcowego).

– 2 – 3 tygodnie

Przyrosty mają jedynie charakter wewnętrzny. Pośrednie przyrostyniekoniecznie stanowią produkt, z którego klient byłby w stanie skorzystać.Każdy przyrost powinien trwać 2-3 tygodnie, oraz zawierać kilka opowieściużytkownika.

35



Znajdź metaforę dla systemu

• Metafora:– Wyjaśnia działanie

systemu wterminachzrozumiałych dlaklienta

Sterowiec? Totaka łódka, tyle, żepływa w powietrzua nie po wodzie.

Kolejne zalecenie metodyki XP, to wyjaśnienie działania systemu za pomocąmetafory, czyli w terminach zrozumiałych dla klienta. Przykładowo możemypowiedzieć, że sterowiec to taka łódka, która pływa w powietrzu. Jeżeli klientznał pojęcie łódki, a nie znał sterowca, to na tej podstawie będzie w stanieprzybliżyć sobie obraz systemu.Metafora przydaje się zwłaszcza do ukrycia terminów technicznych, np.zamiast mówić relacja w bazie danych przechowująca dane faktur, możnapowiedzieć: komputerowy segregator z fakturami.

36



Gra planistyczna

Pisze opowieść Dzieli opowieśćSzacują opowieść

Zaduża!

Klient KlientInformatycy

Klient sam wybiera, w jakiej kolejności funkcje będą implementowane. Robi topodczas gry planistycznej. Na początku, podczas rozmów dot. wymagańsystemu spisuje on opowieści użytkownika. Informatycy szacują rozmiaropowieści, podając liczbę osobo-dni potrzebnych do jej zrealizowania. Jeżeliokazuje się, że opowieść jest za duża (np. wykracza poza jeden przyrost),wówczas dzieli się ją na 2 mniejsze. Czasem dana opowieść jest też zbytmała (np. jej realizacja zajęłaby kilkanaście minut) - wtedy łączy się ją z innąopowieścią.

37



Gra planistyczna

Pisze opowieść Wybiera zakresSzacują opowieść

Więcej

kolorów 9 h

Klient KlientInformatycy

Więcej

kolorów

Więcej

kolorów

Więcej

opcji9 h6 h

W momencie kiedy mamy już spisane wstępne opowieści i oszacowane przezinformatyków, klient wybiera zakres kolejnych przyrostów. On zna kosztkażdej opowieści i może zadecydować czy będzie ona realizowana czy teżnie, oraz kiedy będzie realizowana, czyli do którego dwutygodniowegoprzyrostu należy ją przypisać.

38



CMM & Zarządzanie zmianą

Żądaniezmiany

Err

Użytkownik S.C. Manager

Żądaniezmiany

Programista

Raportzmiany

KierownictwoDecyzja

Poleceniezmiany

Menadżer OK

Kolejna praktyka, która różni się znacznie w stosunku do metodyknastawionych na dyscyplinę to podejście do zmian.Przykładowo, CMM proponuje następujący proces zarządzania zmianą.Najpierw użytkownik zapisuje żądanie zmiany, następnie kierownikzarządzania konfiguracją wysyła je do programisty, który analizuje zmianę iprzygotowuje odpowiedni raport. Na tej podstawie kierownictwo wydajedecyzję, czy zmiana jest dopuszczalna, czy też nie.Jak widać, proces ten jest skomplikowany, więc przetwarzanie zmian w tymmodelu jest bardzo kosztowne i czasochłonne.

39



Zarządzanie zmianą w XP

Klient

Zmieńmywymagania

Programiści

OK OK OK OK

XP proponuje zupełnie inne podejście bazujące na dobrej współpracy zklientem.Po prostu zakłada, że klient w dowolnym momencie może zmienić zdanie izaproponować zmianę wymagań.Nie mieliśmy na początku dokładnego kontraktu, który określałby zakresdziałań oraz koszt projektu. W XP klient płaci na bieżąco za wykonaną pracę izdaje sobie sprawę z tego, że zmiana elementów już zaimplementowanychbędzie go kosztowała dodatkowo. Dzięki temu informatycy nie muszą sięmartwić, gdyż zawsze dostaną wynagrodzenie za swoją pracę.

40



Zarządzanie zmianą w XP

Klient

Mamy problem.Zmieńmy wymagania

Programiści

OK

Działa to również w drugą stronę - jeżeli programiści dostrzegą pewienproblem i zaproponują rozwiązanie, które zmienia wymagania - klient ma donich zaufanie i również zgadza się na przedstawione rozwiązanie.

41



Testy akceptacyjne

Klient Tester

FailureSuccess

Kolejna ważna praktyka w programowaniu ekstremalnym, to testowanieakceptacyjne. Testy akceptacyjne, to testy, które pochodzą od klienta. Klient wten sposób dokładnie określa, jak system musi się zachować w określonychwarunkach, aby zaspokoić jego potrzeby.Najlepiej gdy testy te mogą być wykonywane automatycznie, więc gdy sązapisane w języku skryptowym. Niestety - klient rzadko kiedy posiadaumiejętności programistyczne. Z pomocą przychodzi tester - czyli osoba,której zadaniem jest zapisanie testów klienta w formie skryptów testowych.W momencie kiedy mamy już takie skrypty, zyskujemy 2 rzeczy:-po pierwsze, klient jest pewien, że system spełnia jego wymagania-uruchamiając testy na bieżąco jesteśmy w stanie powiedzieć, jak wyglądapostęp projektu, czyli ile % funkcjonalności zostało już zaimplementowane.Obrazowo pokazuje to wykres na slajdzie - poszczególne słupki oznaczająposzczególne przyrosty (i1,1 = wydanie 1, przyrost 1, i1,2 = wydanie 1,przyrost 2, itp), kolor fioletowy - liczbę testów, które zostały pomyślniewykonane, natomiast czerwony - liczbę testów wykonanych błędnie.Obserwując zmianę takiego wykresu w czasie, widzimy, że kolor czerwonypowoli przechodzi w fioletowy, czyli pewne partie systemu zostałyzaimplementowane. Słupki cały czas rosną w czasie, gdyż przy każdymprzyroście mamy coraz więcej funkcjonalności, a co za tym idzie - corazwięcej przypadków testowych.

42



Plan wykładu



• Czynniki ryzyka

Następne slajdy pokazują, w jaki sposób XP radzi sobie z jakością tworzonegosystemu…

43



Zapewnianie jakości

• Dbaj o prostotę• Unikaj optymalizacji• Dla każdej jednostki kodu

opracuj NAJPIERW zestawtestów, potem pisz kod

• Automatyczne wykonanietestów

• Refaktoryzacja

Jakość ta jest również zapewniana w odmienny sposób niż w przypadkumetodyk tradycyjnych:-po pierwsze - XP stawia na prostotę rozwiązań (optymalizować kod należytylko wtedy, gdy jest to konieczne)-po drugie - przed rozpoczęciem kodowania należy przygotować przypadkitestowe (ang. test-first-coding)-tak przygotowane testy są następnie jak najczęściej wykonywaneautomatycznie - dzięki czemu na bieżąco wychwytywane są błędy-do poprawy czytelności kodu stosuje się refaktoryzację

44



Refaktoryzacja

Nowawersja

Starawersja

Lepszawersja

RefaktoryzacjaMała

zmiana

Starawersja

Nowawersja

Duża zmiana

Ta samafunkcjonalność

Więcej informacji o refaktoryzacji otrzymacie Państwo podczas kolejnegowykładu. Po krótce jednak - refaktoryzacja to sposób na systematycznąpoprawę jakości kodu i ewolucję architektury produktu.Załóżmy, że mamy do przeprowadzenia dużą zmianę w oprogramowaniu.Zamiast wykonywać ją od razu na starej wersji systemu, robi się to stopniowo:-najpierw tworzymy lepszą wersję systemu o tej samej funkcjonalności(czyścimy kod za pomocą przekształceń refaktoryzacyjnych), dzięki czemu wkolejnym kroku możemy osiągnąć nową wersję, wprowadzając już tylko małązmianę.Takie podejście pozwala na bezpieczne wprowadzanie zmianarchitektonicznych - w przypadku kiedy dotychczasowa architektura nie pasujedo nowych wymagań.

45



Zapewnianie jakości

• Kod musi przejść wszystkietesty jednostkowe zanimprzekażesz go do eksploatacji

• Dla każdego wykrytego błęduutwórz zestaw testów

• Często integruj kod• Często wykonuj testy

akceptacyjne i publikuj ichwyniki

Kolejnych kilka zasad związanych z zapewnieniem jakości:-Zanim udostępni się zmiany dla innych programistów, należy dokładnieprzetestować go za pomocą testów jednostkowych-Jeżeli wykryjemy jakiś błąd na przetestowanym kodzie, oznacza to, że sitozłożone z testów jednostkowych w pewnym miejscu jest „nieszczelne”. Wtakiej sytuacji należy je „uszczelnić” dodając nowe przypadki testowezapobiegające przedostaniu się tego błędu w przyszłości-Należy również jak najczęściej uruchamiać testy integracyjne i akceptacyjne

46



Plan wykładu



• Czynniki ryzyka

Ostatnia praktyka, jaką przedstawimy na tym wykładzie to programowanieparami. Wiele osób ze środowiska związanego z informatyką bardzokrytycznie spogląda na takie pomysły, lecz osoby, które próbująwykorzystywać zwinne metodyki mówią, że to działa… O co zatem chodzi wprogramowaniu parami?

47



Programowanie parami

if (x=y) z=0;

Autor Recenzent

Powinno byćx==y!

W tym podejściu, przy jednym komputerze siedzą 2 osoby jednocześnie: autori recenzent. Autor pisze kod, natomiast recenzent na bieżąco go przegląda iwychwytuje defekty.Autor jest bardzo skupiony na tworzeniu kodu, a recenzent ma więcej czasuna myślenie. Może się okazać zatem, że znajdzie lepszy sposób narozwiązanie problemu, lub np. dostrzeże problemy związane z testowaniemobecnego kodu, lub po prostu wychwyci błąd w programie.

48




• Cały produkt jestkodowany w parach

• Standard kodowania• Tylko jedna para

integruje kod w danejchwili

• Pary się zmieniają

XP zaleca, żeby każdy fragment kodu powstał poprzez programowanieparami.Aby można było wygodnie pracować w parach, potrzebny jest wspólnystandard kodowania dla całego zespołu.XP zakłada również, że będą następować częste zmiany w parach, tak abykażda osoba pracowała nad każdym fragmentem systemu. Ma to dodatkowązaletę w postaci przepływania wiedzy pomiędzy poszczególnymiprogramistami. Dodatkowo w momencie kiedy jeden programista odejdzie zzespołu, dla każdego fragmentu kodu znajdziemy inną osobę, która będzieznała ten fragment.

49




• Kod jest własnościącałego zespołu

• System zarządzaniawersjami!

• Otwarta przestrzeńpracy dla zespołu

W XP nie ma osoby odpowiedzialnej za każdą część kodu - kod jestwłasnością całego zespołu.Nie da się wydajnie pracować parami, jeżeli nie ma w firmie systemuzarządzania wersjami, np. CVS.Wymagana jest również otwarta przestrzeń pracy dla zespołu - abyposzczególne osoby mogły się łatwo komunikować.

50



Plan wykładu



• Czynniki ryzyka

Czy XP ma jakieś wady? Lub jakieś czynniki ryzyka, które znacznie utrudniająjego zastosowanie w praktyce?

51



Czynniki ryzyka

• Klient pracuje cały czas zzespołem

• Brak dokumentacji• Brak fazy projektowania• Krótka perspektywa

planowania

XP nie jest rozwiązaniem uniwersalnym: ma również wiele czynników ryzyka,które mogą się okazać wadami:-Założenie, że klient przez cały czas pracuje z zespołem może się okazaćnierealne - rzadko który klient może sobie pozwolić na oddelegowaniejednego pracownika na kilka miesięcy (gdyż tyle może trwać projekt)-Brak dokumentacji z jednej strony powoduje przyspieszenie projektu, leczczasem może się okazać, że po pewnym czasie trzeba wrócić do prac nadsystemem (np. dodać nową funkcjonalność). Wtedy, bez odpowiedniejdokumentacji, trudno przypomnieć sobie za co poszczególne fragmenty kodubyły odpowiedzialne.-Niektórzy zarzucają również brak fazy projektowania - twierdzą, żerozwiązania powstają za bardzo ad hoc-Krótka perspektywa planowania (planuje się tylko kolejne wydanie) niepozwala przewidzieć, kiedy system będzie ukończonyTe wady przyczyniają się do tego, że niektórym ludziom trudno skłonić się dowypróbowania zwinnych podejść do wytwarzania oprogramowania.

52



Podsumowanie

• Manifest zwinności:– Zorientowanie na ludzi i

komunikację– Dopuszczenie zmian– Jakość oprogramowania

• Gra planistyczna• Programowanie parami• Wady XP

Wreszcie

Podsumujmy wykład:-Manifest zwinności to zbiór zasad wspólnych dla zwinnych metodykwytwarzania oprogramowania. Są one zorientowane na ludzi i komunikacjęmiędzy nimi, dopuszczają dowolne zmiany w wymaganiach, oraz stawiają najakość oprogramowania, a nie obszerną dokumentację-XP jest jedną ze zwinnych metodyk wytwarzania oprogramowania -ważniejsze elementy tej metodyki to: gra planistyczna, programowanie parami,testowanie jednostkowe, ścisła współpraca z klientem-XP nie jest złotym rozwiązaniem - ma również pewne wady, np. założenie, żeklient pracuje z zespołem, brak dokumentacji, krótka perspektywa planowania

53



Literatura

• K. Beck. Extreme Programming Explained.Addison-Wesley, 1999

• K. Beck and M. Fowler. Planning ExtremeProgramming. Addison-Wesley, 2000

Documents

Koncepcja wyk adu: Jerzy Nawrocki/Łukasz Olekwazniak.mimuw.edu.pl/images/d/db/Io-12-wyk-color.pdf · Kontrola jakości artefaktów Język UML, cz. I Język UML, cz. II Metody formalne