Proces wytwarzania oprogramowania

Transkrypt

1 Proces wytwarzania oprogramowania

2 Proces wytwarzania oprogramowania Proces wytwarzania oprogramowania (zwany również cyklem wytwarzania oprogramowania) to proces tworzenia lub rekonstrukcji systemu informatycznego wraz z modelami i metodologiami używanymi w jego realizacji Wybrane etapy procesu wytwarzania oprogramowania: Specyfikacja wymagań Analiza Projektowanie Implementacja Testowanie Wdrożenie i pielęgnacja

3 Motywacja Programy z początku ery informatyki były nieskomplikowane, tworzone zazwyczaj do celów naukowych przez przyszłych użytkowników Rozwój sprzętu komputerowego i języków programowania sprawił, że zaczęto tworzyć bardziej złożone systemy przeznaczone dla szerszego grona odbiorców Na pewnym etapie zauważono, że o sukcesie projektu informatycznego decydują nie tylko umiejętności programistów, ale i praca całego zespołu oraz w dużej mierze organizacja samego procesu wytwarzania oprogramowania

4 Motywacja Konkurencja wymusiła poszukiwanie nowych sposobów na poprawę efektywności procesu wytwarzania oprogramowania W efekcie powstało wiele modeli opisujących cykl życia systemu informatycznego i sposób realizacji procesu wytwórczego Na bazie tych modeli powstały tzw. metodyki projektowe (zestaw metod i procedur pozwalających zespołowi projektowemu realizować cykl życia systemu)

5 Cykle życia i wytwarzania Cykl życia systemu informatycznego szereg wzajemnie zależnych etapów, począwszy od ujawnienia potrzeby budowy systemu informatycznego, prezentacji jego idei, konstrukcję, użytkowanie, przystosowane do ewentualnych zmian funkcjonowania a kończąc na wycofaniu z eksploatacji Cykl wytwarzania systemu informatycznego fragment cyklu życia SI związany z procesem wytwórczym oprogramowania Cykl życia projektu okres od początku do zakończenia projektu informatycznego

6 Przeznaczenie modeli cyklu wytwarzania SI Formalnie określony sposób realizacji projektu (plan projektu, metodologia budowy systemu) Uporządkowanie przebiegu prac Ułatwienie planowania zadań Monitorowanie przebiegu realizacji zadań

7 Podstawowe modele cyklu życia SI Kaskadowy Przyrostowy Spiralny Prototypowanie Programowanie odkrywcze Montaż z gotowych elementów

8 Model kaskadowy (wodospadu) Specyfikacja wymagań Analiza Projektowanie Implementacja Testowanie Wdrożenie

9 Model kaskadowy (wodospadu) Stosowany w projektach o dobrze zdefiniowanych wymaganiach Etapy realizowane są w ściśle określonej kolejności Etap musi być zakończony przed przejściem do następnego Modele, projekty, kod lub dokumentacja wytworzone w danym etapie przekazywane są do następnego etapu

10 Model kaskadowy Zalety Naturalny zrozumiały i dobrze zdefiniowany ciąg kroków oraz dokumentów i produktów, które należy wytworzyć w każdym kroku Łatwość zarządzania projektem (ułatwia planowanie, harmonogramowanie oraz monitorowanie) Wady Silnie zależy od stabilności wymagań Weryfikacja zgodności z wymaganiami dopiero w końcowych etapach Marginalizacja roli klienta Wysokie koszty naprawy błędów

11 Model kaskadowy z iteracjami Specyfikacja wymagań Analiza W modelu kaskadowym z iteracjami jest możliwość powrotu do każdego z wcześniejszych etapów. Zaleca się by iteracje były z góry zaplanowane Projektowanie Implementacja Testowanie Wdrożenie

12 Model kaskadowy kierowany dokumentami Model opracowany przez armię amerykańską Bazuje na modelu kaskadowym Każdy etap kończy się opracowaniem dokumentacji W tradycyjnym modelu kaskadowym dokumentacja jest warunkiem przejścia do kolejnego etapu W modelu kierowanym dokumentami potrzebna jest jeszcze akceptacja klienta Dodatkową zaletą jest możliwość przerwania realizacji projektu w jednej firmie i wznowienie realizacji w innej (po przekazaniu jej kompletu dokumentów) Dodatkowe wady polegają na przestojach związanych z analizą dokumentacji przez klienta oraz dużym nakładzie pracy na opracowanie dokumentów

13 Model przyrostowy Rozpoczyna się od specyfikacji wymagań i wykonania wstępnego projektu (architektury) Następnie wybierany jest pewien podzbiór wymagań i następuje jego realizacja (przyrost), czyli szczegółowa analiza, projektowanie, implementacja i testowanie W efekcie powstaje wersja systemu, która może być dostarczona i wdrożona u klienta W kolejnej iteracji wybierany jest kolejny podzbiór wymagań i następuje jego realizacja Iterację wykonywane są do momentu realizacji wszystkich wymagań

14 Model przyrostowy Określenie wymagań Projekt ogólny Proces realizowany iteracyjnie Wybór podzbioru funkcji Projekt szczegółowy, implementacja i testy Dostarczenie zrealizowanej części systemu

15 Model przyrostowy Zalety Szybka implementacja funkcjonalności priorytetowych lub obarczonych dużym ryzykiem Możliwość wczesnego wdrożenie Skrócenie przerw w kontaktach z klientem w porównaniu do modelu kaskadowego Wady Problem z wyodrębnieniem w miarę niezależnych grup funkcjonalności Konieczność wytworzenia dodatkowych modułów niezbędnych do działania kolejnej wersji

16 Model spiralny Planowanie nakreślenie możliwych opcji (alternatyw) kolejnego wydania systemu na podstawie wymagań wstępnych lub celów wyznaczonych przez klienta Analiza ryzyka identyfikacja źródeł ryzyka i szacownie wielkości ryzyka dla każdej z możliwych alternatyw kolejnego wydania systemu Konstrukcja wytworzenie kolejnego wydania systemu ( mały wodospad analiza, projektowanie, implementacja, test i wdrożenie) Testowanie ocena kolejnego wydania systemu i wskazanie nowych wymagań lub modyfikacja istniejących

17 Model spiralny PLANOWANIE ANALIZA RYZYKA Planowanie na podstawie wyniku oceny klienta Wymagania początkowe Analiza ryzyka dla wymagań początkowych Analiza ryzyka w oparciu o reakcję klienta Ocena klienta Kolejne wydania TESTOWANIE KONSTRUKCJA ( mini model kaskadowy)

18 Model spiralny Zalety Szybka reakcja na pojawiające się ryzyka i oczekiwania klienta Ciągła weryfikacja produktu przez klienta zwiększa szanse na wytworzenie satysfakcjonującego rozwiązania Wady Wymagana umiejętność szacowania ryzyka projektu informatycznego

19 Prototypowanie Polega na budowaniu kolejnych przybliżeń systemu aż prototyp stanie się w pełni funkcjonalnym systemem Każdy kolejny prototyp jest oceniany przez klienta i wynik tej oceny trafia do projektantów Po akceptacji prototypu przez klienta następuje pełna specyfikacja wymagań i realizacja systemu w modelu kaskadowym Ponieważ podstawowym zadaniem prototypu jest pomoc w lepszym określeniu wymagań, budowę i weryfikację prototypu można uznać za specyficzny sposób realizacji fazy określania wymagań tradycyjnego modelu kaskadowego.

20 Prototypowanie Ogólne określenie wymagań Budowa prototypu nie Weryfikacja przez klienta tak Pełne określenie wymagań Realizacja pełnego systemu

21 Prototypowanie Zalety Pozwala uściślić wymagania i uniknąć błędu ich niewłaściwej specyfikacji Możliwe do stosowania w przypadku, gdy są problemy w jednoznacznym ustaleniu wymagań Wczesne wykrycie ewentualnych nieporozumień pomiędzy klientem a wytwórcą Wady Dodatkowy koszt budowy prototypu (tylko niewielkie fragmenty prototypu można wykorzystać w właściwym systemie) Nieporozumienia z klientem wynikające z długiego czasu oczekiwania na działający system w porównaniu z bardzo krótkim okresem wytwarzania prototypu

22 Metody budowy prototypu Realizacja tylko trudnych funkcjonalności Języki wysokiego poziomu (Lisp, Smalltalk, Prolog) i specjalizowane języki prototypowania Wykorzystanie gotowych komponentów Generatory interfejsu użytkownika, generatory oprogramowania, narzędzia typu CASE, Szybkie programowanie, tj. tylko kod, bez testowania

23 Programowanie odkrywcze Rozpoczyna się od bardzo ogólnego określenia wymagań Następnie budowany jest system (nie prototyp!) System jest weryfikowany przez klienta W przypadku negatywnej oceny tworzona jest nowa wersja na bazie poprzedniej Proces kończy się z chwilą gdy jedna z wersji zostanie zaakceptowana przez klienta

24 Programowanie odkrywcze Ogólne określenie wymagań Budowa systemu Przetestuj system nie System działa poprawnie tak Dostarcz system

25 Programowania odkrywcze Zalety Możliwość stosowania nawet w przypadku trudności w ustaleniu wstępnych wymagań Wady Problem z zachowaniem sensownej struktury systemu praktycznie uniemożliwia realizację większych, niezawodnych systemów Konieczność testowania przy współudziale klienta, bo model nie przewiduje pełnego określenia wymagań

26 Montaż z gotowych elementów Polega na wykorzystywaniu gotowych elementów w tworzonym systemie Gotowe elementy mogą być wykorzystywane na dowolnym etapie projektu Zwykle gotowe elementy wykorzystuje się na etapie implementacji Istnieje również możliwość wykorzystania gotowych modeli funkcjonowania pewnych typów organizacji (tzw. designware) Gotowym elementem mogą być modele, projekty, komponenty stworzone w ramach wcześniejszych projektów Gotowe elementy można też nabyć od innych dostawców

27 Montaż z gotowych elementów Zalety Wysoka niezawodność Redukcja kosztów Efektywne wykorzystanie specjalistów Wady Konieczność przygotowania gotowego elementu do użycia w nowym systemie Możliwość uzależnienia od dostawcy gotowego elementu

28 Który model wybrać? Model odkrywczy prosty problem, system na własny użytek Model kaskadowy lub montaż z gotowych elementów wymagania dobrze wyspecyfikowane, doświadczenie w realizacji podobnych projektów Prototypowanie problem ze specyfikacją wymagań

29 Rational Unified Process Rational Unified Process (RUP) to proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę Rational Software Corporation (firma została obecnie przejęta przez IBM) Proces RUP nie jest pojedynczym, ściśle określonym procesem, ale raczej szablonem procesu

30 Rational Unified Process Został zaprojektowany w celu przystosowania do charakteru konkretnej organizacji, konkretnego zespołu projektowego lub nawet charakteru konkretnego projektu Z szablonu RUP można wybrać elementy w zależności od konkretnych potrzeb

31 Rational Unified Process Rational Unified Process (RUP) to także nazwa oprogramowania, opracowanego przez Rational Software (obecnie dostępnego w IBM) zawierającego hipertekstową bazę wiedzy z przykładowymi artefaktami oraz szczegółowymi opisami wielu typów czynności Process RUP definiowany jest także w produkcie Rational Method Composer (RMC), który pozwala na tworzenie spersonalizowanych wersji RUP

32 Iteracyjne wytwarzanie oprogramowania Wytwarzanie oprogramowania w kolejnych iteracjach, pozwala skupić się w pierwszej kolejności na obszarach najbardziej ryzykownych (np. najmniej rozpoznanych) W idealnym przypadku każda iteracja kończy się stworzeniem wykonywalnego artefaktu - pomaga to zredukować ryzyko w projekcie, otrzymujemy szybciej opinie od odbiorców oprogramowania a programistom pozwalamy skupić się na węższej dziedzinie

33 Architektura bazująca na komponentach Pozwala na stworzenie systemu, który jest łatwo rozszerzalny, intuicyjnie zrozumiały i wspomaga ponowne użycie (komponent to zbiór powiązanych obiektów) RUP skupia się na stworzeniu prostej architektury w początkowych iteracjach Ewoluuje ona w każdej iteracji zbliżając się do architektury finalnej Poprzez iteracyjne wytwarzanie oprogramowania zyskujemy możliwość stopniowej identyfikacji komponentów, które mogą być w dalszej części: zakupione, zbudowane, lub użyte ponownie

34 Wizualne modelowanie oprogramowania Abstrakcja projektowania od kodu i przedstawienie koncepcji za pomocą bloków graficznych może być efektywnym sposobem aby pokazać perspektywę rozwiązania Reprezentacja graficzna jest produktem pośrednim pomiędzy analizą procesu biznesowego, a implementacją Model w tym kontekście jest formą wizualizacji oraz uproszczeniem bardziej skomplikowanego projektu RUP specyfikuje wymagane modele i opisuje dlaczego są wymagane

35 Kontrola i weryfikacja jakości oprogramowania Ocena jakości jest najczęstszym słabym punktem projektów programistycznych ponieważ jest często planowana po fakcie budowy systemu i czasami obsługiwana przez inny zespół RUP pomaga w planowaniu kontroli jakości i jej ocenie poprzez wbudowanie jej w cały proces i zaangażowanie w nią wszystkich członków zespołu Proces koncentruje się na spełnieniu wymaganego poziomu jakości i zapewnia mechanizmy do pomiaru tego poziomu

36 Zarządzanie zmianami w oprogramowaniu RUP definiuje metody śledzenia, ewidencji i kontroli zmian Zdefiniowane są także tzw. secure workspaces (bezpieczne przestrzenie robocze), które pozwalają na zagwarantowanie, że zmiany w innych systemach nie wpłyną na system tworzony Koncepcja ta jest ściśle powiązana z tworzeniem architektury zorientowanej komponentowo

37

38 Struktura organizacyjna RUP proponuje strukturę zespołów w dwóch obszarach biznesowym (business unit) projektowym Zadaniem zespołu biznesowego jest koordynowanie funkcji i zasobów wykorzystywanych w wielu projektach z zastosowaniem wspólnej technologii i zasad

39 Zalety RUP RUP jest procesem iteracyjnym zakładającym budowanie systemu w kolejnych przebiegach Po zakończeniu iteracji produkowany jest fragment systemu spełniający wymagania klienta, jest on następnie udostępniany W ten sposób zespół analityczno-projektowy otrzymuje szybko sygnał zwrotny od klienta, który umożliwia bieżącą ocenę ryzyka niepowodzenia projektu jak również pozwala stwierdzić czy zespół analityczno-projektowy dobrze zrozumiał wymagania klienta wobec systemu

40 Zalety RUP W razie wystąpienia problemów zostaną one szybko wykryte i zespół analityczno-projektowy będzie mógł wdrożyć odpowiednie postępowanie zaradcze Podejście iteracyjne powoduje gwałtowną redukcję ryzyka niepowodzenia projektu już po zakończeniu pierwszej iteracji

41 Wady RUP Rup to metodyka ciężka i kosztowna Wymaga obszernego dokumentowania procesu Ogranicza inicjatywę i samodzielność Wysokie koszty administracyjne Sztywne procedury (np. audytu)

42 Metodyka PRINCE2 Projects in a Controlled Environment tzn. Projekty w sterowanym środowisku brytyjska agenda rządowa Central Computer and Telecommunications Agency (CCTA) opublikowało standard pod nową nazwą PRINCE PRINCE2 opublikowany jako ogólna metoda zarządzania projektami niezależna od dziedziny biznesowej zastosowania ostatnie zmiany opublikowane przez Office for Government Commerce (OGC) następcę CCTA

43 Uruchamianie projektu Przygotowanie projektu do uruchomienia Ma zapewnić, że projekt będzie wart ponoszonych kosztów i że da się go zrealizować Informacją wejściową dla procesu jest Zlecenie Przygotowania Projektu (Project Mandate) W proces zaangażowane jest wyższe kierownictwo organizacji, które ustanawia i wybiera Komitet Sterujący (Project Board), który nadzoruje projekt i wybiera Kierownika Projektu

44 Zarządzanie strategiczne projektem Realizuje funkcje, za które odpowiedzialny jest Komitet Sterujący Kierownik Projektu informuje Komitet Sterujący w raportach okresowych o stanie projektu Bieżące zarządzanie pozostawione jest w wyłącznej kompetencji Kierownika Projektu

45 Zarządzanie wytwarzaniem produktów PRINCE2 to metodyka oparta na produktach; produktem może być rzecz materialna np. książka Może nim być też rzecz bardziej niematerialna np. poziom usług serwisowych W zasadzie wszystko, co zostało wytworzone przez projekt zgodny z PRINCE2, włączając w to dokumenty jest produktem Produkt może być wytworzony przez kogokolwiek, także przez zewnętrznego dostawcę.

46 Zamykanie projektu Według metodyki PRINCE2 projekty muszą być zamykane w sposób uporządkowany i kontrolowany Wszystkie doświadczenia zdobyte w trakcie prowadzenia projektu są rejestrowane, tworzony jest dokument przekazania i planowany jest przegląd powdrożeniowy Po zakończeniu projektu w zaplanowanym momencie pozwalającym na należytą ocenę skutków biznesowych projektu przeprowadzany jest przegląd poprojektowy

47 Jakość w środowisku projektowym Celem projektu jest wytworzenie produktów, zgodnych z ich przeznaczeniem, zaspokajających potrzeby oraz oczekiwania jakościowe klienta Oczekiwania jakościowe są określone w Zleceniu Projektu (Project Mandate), Założeniach Projektu (Project Brief) oraz Dokumencie Inicjującym Projekt (Project Initiation Document)

48 Sterowanie zmianami W PRINCE2 wszystkie zmiany są traktowane jako zagadnienia projektowe: wnioski o zmianę dotyczące zmiany w wymaganiach albo produkcie odstępstwo rejestrowane kiedy produkt nie spełnia wymagań. sugestie zapytania zagadnienia ogólne

49 Sterowanie zmianami Obsługa wszystkich zagadnień projektowych jest w gestii Kierownika Projektu Ich zgłoszenia muszą być udokumentowane w Rejestrze zagadnień (Issue Log) Wnioski o zmianę muszą być zaakceptowane przez Komitet Sterujący lub Komitet ds. zmian (Change Authority) Przed akceptacją zmiany musi być wykonana analiza wpływu zmiany Odstępstwa (Off specification) mogą być załatwiane w ramach działań korygujących przez Kierownika Projektu o ile nie wykraczają one poza określone dla projektu granice tolerancji Komitet Sterujący może zaakceptować odstępstwa bez uruchamiania działań korygujących definiując je jako ustępstwo

50 Mocne strony PRINCE2 Stosowanie tej metodyki zapewnia wysoką standaryzację i powtarzalność projektów o wspólnym podejściu, terminologii i dokumentacji co zapewnia możliwość doskonalenia kompetencji Metodyka w sposób racjonalny opiera się na najlepszych praktykach w zarządzaniu projektami Wprowadza management by exception jako podstawową zasadę, która zapewnia Kierownikowi Projektów swobodę działania bez zbędnej ingerencji, zapewniając jednocześnie zaangażowanie wyższego kierownictwa, wtedy kiedy projekt jest zagrożony wykroczeniem poza granice tolerancji lub przestaje realizować uzasadnienie biznesowe

51 Mocne strony PRINCE2 Sprawuje kontrolę nad startem, realizacją i końcem projektu Każdy z dokumentów wymaganych przez PRINCE2 jest dostarczony jako szablon zawierający wymagane metrykę, rozdziały i pola informacyjne co zapewnia przejrzystość, standaryzację i kompletność dokumentacji Przewiduje możliwość adaptacji do specjalnych potrzeb organizacji, programu lub projektu Jej stosowanie nie wymaga opłat autorskich Materiały PRINCE2 są opublikowane i szeroko dostępne co ogranicza prace nad wypracowywaniem własnych standardów i przygotowaniem materiałów szkoleniowych

52 Słabości PRINCE2 Dużo organizacji cierpi na syndrom PINO (Prince In Name Only tzn. PRINCE2 tylko z nazwy), wybierając bez głębszej analizy tylko niektóre składniki metodyki nie zwracając uwagi na podstawowe zasady PRINCE2 kładzie duży nacisk na dokumentowanie jako narzędzie sprawnej kontroli sposobu realizacji projektu W niektórych organizacjach dokumenty stają się jednak celem samym w sobie, a rzeczywiste projekty kończą się niepowodzeniem

53 Słabości PRINCE2 Podobnie uwaga jaką zwraca PRINCE2 na potrzebę dobrej organizacji i regularną wymianę informacji pomiędzy zainteresowanymi odbierana jest niesłusznie jako zachęta do ciągłych bezproduktywnych spotkań zabierających czas niezbędny na rzeczywistą pracę PRINCE2 nie definiuje wprost analizy wymagań tak więc może prowadzić do niepowodzenia projektu z uwagi na przyjęcie fałszywych założeń (z drugiej strony jasno jest określone, kto ponosi odpowiedzialność za przyjęcie złych założeń i akceptację nietrafnego uzasadnienia biznesowego a przesłanki tych decyzji są udokumentowane i mogą stanowić nauczkę na przyszłość)

54 Słabości PRINCE2 Zbyt ścisłe przestrzeganie PRINCE2 bez odpowiedniej adaptacji do realiów biznesowych może być zbyt pracochłonne w zastosowaniu do małych projektów Niezbyt "zwinna"

55 Krytyka podejścia zorientowanego na procedury i dokumenty Zbyt dużo czasu poświęca się na tzw. papierkową robotę zamiast na tworzenie oprogramowania Dokumenty nie zawsze odzwierciedlają stan faktyczny, powstają tylko dlatego że są wymagane Pracownicy koncentrują się na realizacji procesu a nie na poprawie jakości tworzonego produktu Brak możliwości (lub zbyt duże koszty) zmian procedur (np. po uzyskaniu określonego certyfikatu) Dyscyplina zabija inicjatywę i elastyczność

56 Narodziny programowania ekstremalnego (XP) Jak odchudzić procesy wytwarzania oprogramowania przy zachowaniu lub nawet polepszeniu jakości tworzonego systemu? Powstanie lekkich (zwinnych, ang. Agile) metodyk rozwoju oprogramowania Programowanie Ekstremalne (ang. Extreme Programming) jako przykład lekkiej metodyki Kent Beck

57 Charakterystyka lekkich metodyk XP i inne lekkie podejścia, wyrosły na pragmatycznym gruncie sukcesu tzw. "dobrych praktyk" programistycznych Praktyki te obejmują m. in.: aktywny udział klienta w pracach rozwojowych szybkie sprzężenie zwrotne pomiędzy formułowaniem wymagań biznesowych a ich realizacją nieustanną pielęgnację jakości wytwarzanego oprogramowania poprzez intensywne testowanie refaktoryzację* oraz konstrukcję efektywnego zespołu

58 Manifest zwinności (rok 2001) Kent Beck - twórca metody kart CRC stosowanej podczas analizy obiektowej, autor narzędzi xunit - wspomagających testowanie jednostkowe oraz twórca XP Alistair Cockburn - autor rodziny zwinnych metodyk Crystal, oraz książek poświęconych inżynierii wymagań (głównie przypadkom użycia) Martin Fowler - twórca pomysłu refaktoryzacji, autor świetnej książki UML Distilled (UML w kropelce) i inni

59 Manifest zwinności Jednostki i interakcje są ważniejsze niż procesy i narzędzia Działające oprogramowanie jest ważniejsze niż obszerna dokumentacja Współpraca z klientem jest ważniejsza niż negocjacja kontraktu Nadążanie ze zmianami jest ważniejsze niż trzymanie się planu

60 Wartości XP Komunikacja Prostota Sprzężenie zwrotne Odwaga Szacunek

61 Komunikacja Budowanie systemów informatycznych 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ęki czemu wiedza o systemie bardzo szybko rozprzestrzenia się w zespole Dzięki komunikacji wszyscy członkowie zespołu mają takie samo wyobrażenie przyszłego systemu i wiedzą w jakim kierunku projekt dąży

62 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 podstawie dobudowujemy resztę Dzięki refaktoryzacji jakość produktu jest stale na najwyższym poziomie Dzięki prostocie programiści skupiają się na projektowaniu i kodowaniu na potrzeby bieżącego dnia, a nie robią nic na wyrost

63 Sprzężenie zwrotne System ważna jest odpowiedź systemu, otrzymywana w procesie testowania jednostkowego Klient przygotowuje testy akceptacyjne wraz z testerem; dzięki takim testom można sprawdzić w jakim stanie znajduje się aktualnie budowany system Zespół w momencie kiedy klient proponuje nowe wymagania zespół podaje szacunki ile czasu zajmie ich zaimplementowanie; dzięki temu klient może podjąć decyzje, czy wymaganie będzie realizowane od razu, w przyszłości lub też w ogóle

64 Odwaga Odwaga jest potrzebna, aby przestrzegać zasady projektowania i kodowania wg aktualnych potrzeb, bez zastanawiania się co będzie potrzebne w przyszłości Odwaga, aby nie angażować się za bardzo w projektowanie i od razu przejść do kodowania Odwaga jest potrzebna, aby zrefaktoryzować kod, wtedy kiedy to jest potrzebne, aby nie bać się refaktoryzacji Jeżeli okaże się, że pewien fragment kodu jest już nieprzydatny, lub musi zostać zmieniony, do podjęcia decyzji o wyrzuceniu takiego kodu potrzeba dużo odwagi

65 Szacunek 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 innych osób będzie utrudniona, lub niemożliwa i stracą one dużo czasu Dzięki dążeniu do najwyższej jakości i szukanie najlepszych rozwiązań projektowych (dzięki refaktoryzacji) innym osobom będzie dużo łatwiej wykorzystać kod napisany przez nas

66 Struktura zespołu XP nie pokazuje wprost struktury zespołu Dwie główne role w zespole pełnią: programiści klient Klient uważany jest za członka zespołu, więc musi przez cały czas pracować razem z informatykami (w jednym pomieszczeniu); czasem nie występuje w tej roli osobiście, lecz za pośrednictwem przedstawiciela klienta

67 Struktura zespołu Role pomocnicze pełnią: tester, którego zadaniem jest napisanie skryptów testowych na podstawie rozmów z klientem coach, to osoba, która pomaga rozwiązywać napotkane problemy tracker natomiast zbiera statystyki dotyczące wykonanych zadań, czasu pracy i tworzy podsumowania postępów projektu

68 Opowieści użytkowników Przedstawiciel klienta jest ciągłym źródłem wymagań Wymagania są dyskutowane z nim na bieżąco, natomiast ślad z tych dyskusji jest przechowywany w formie opowieści użytkowników Każda opowieść jest zapisana w kilku zdaniach na małej kartce papieru Może być oznaczona dodatkowymi atrybutami (np. data utworzenia, typ, numer, rozmiar)

69 Przykład opowieści Numer opowieści: 102 OPOWIEŚĆ: System przechowuje artykuły w formacie PDF. Umożliwia ich dodawanie, listowanie, a także pobieranie. Rozmiar: 3 dni Opowieści są krótkie Opisują funkcję systemu Mają wartość dla klienta Są testowalne

70 Hydrodynamiczny model projektu

71 Hydrodynamiczny model projektu

72 Cykl życia

73 Cykl życia w XP

74 Wydania i przyrosty Każde wydanie ma wartość użytkową i trafia do użytkowników końcowych, dzięki czemu programiści dostają sprzężenie zwrotne Należy stosować częste i krótkie wydania Przyrosty mają charakter wewnętrzny Pośrednie przyrosty niekoniecznie stanowią produkt, z którego klient byłby w stanie skorzystać Każdy przyrost powinien trwać 2-3 tygodnie, oraz zawierać kilka opowieści użytkownika

75 Planowanie Na początku podczas rozmów dotyczących wymagań systemu klient spisuje opowieści użytkownika Informatycy szacują rozmiar opowieści, podając liczbę osobo-dni potrzebnych do jej zrealizowania Jeżeli opowieść jest za duża (np. wykracza poza jeden przyrost), wówczas dzieli się ją na mniejsze Jeżeli opowieść jest też zbyt mała wtedy łączy się ją z inną opowieścią

76 Planowanie W momencie kiedy spisane są wstępne opowieści i oszacowane przez informatyków, klient wybiera zakres kolejnych przyrostów Klient zna koszt każdej opowieści i może zadecydować czy będzie ona realizowana czy też nie, oraz kiedy będzie realizowana, czyli do którego dwutygodniowego przyrostu należy ją przypisać

77 Zarządzanie zmianami Klient w dowolnym momencie może zmienić zdanie i zaproponować zmianę wymagań Klient płaci na bieżąco za wykonaną pracę i wie, że zmiana elementów już zaimplementowanych będzie go kosztowała dodatkowo Działa to również w drugą stronę - jeżeli programiści dostrzegą pewien problem i zaproponują rozwiązanie, które zmienia wymagania - klient ma do nich zaufanie i również zgadza się na przedstawione rozwiązanie

78 Zapewnienie jakości XP stawia na prostotę rozwiązań (optymalizować kod należy tylko wtedy, gdy jest to konieczne) Przed rozpoczęciem kodowania należy przygotować przypadki testowe (ang. test-first-coding) Tak przygotowane testy są następnie jak najczęściej wykonywane automatycznie - dzięki czemu na bieżąco wychwytywane są błędy Do poprawy czytelności kodu stosuje się refaktoryzację

79 Zapewnienie jakości Zanim udostępni się zmiany dla innych programistów, należy dokładnie przetestować go za pomocą testów jednostkowych Klient przygotowuje testy akceptacyjne w których dokładnie określa, jak system musi się zachować w określonych warunkach, aby zaspokoić jego potrzeby Na podstawie stopnia wykonania testów akceptacyjnych można ocenić postęp prac

80 Programowanie parami W tym podejściu, przy jednym komputerze siedzą 2 osoby jednocześnie: autor i recenzent Autor pisze kod, natomiast recenzent na bieżąco go przegląda i wychwytuje defekty Autor jest bardzo skupiony na tworzeniu kodu, a recenzent ma więcej czasu na myślenie; może się okazać zatem, że znajdzie lepszy sposób na rozwiązanie problemu, lub np. dostrzeże problemy związane z testowaniem obecnego kodu, lub po prostu wychwyci błąd w programie

81 Programowanie parami XP zaleca, żeby każdy fragment kodu powstał poprzez programowanie parami Potrzebny jest wspólny standard kodowania dla całego zespołu XP zakłada, że będą następować częste zmiany w parach, tak aby każda osoba pracowała nad każdym fragmentem systemu co ma dodatkową zaletę w postaci przepływania wiedzy pomiędzy poszczególnymi programistami Dodatkowo w momencie kiedy jeden programista odejdzie z zespołu, dla każdego fragmentu kodu znajdziemy inną osobę, która będzie znała ten fragment

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

83 Czynniki ryzyka 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 oddelegowanie jednego pracownika na kilka miesięcy (gdyż tyle może trwać projekt) Brak dokumentacji z jednej strony powoduje przyspieszenie projektu, lecz czasem może się okazać, że po pewnym czasie trzeba wrócić do prac nad systemem (np. dodać nową funkcjonalność); wtedy, bez odpowiedniej dokumentacji, trudno przypomnieć sobie za co poszczególne fragmenty kodu były odpowiedzialne

84 Czynniki ryzyka Niektórzy zarzucają również brak fazy projektowania - twierdzą, że rozwiązania powstają za bardzo ad hoc Krótka perspektywa planowania (planuje się tylko kolejne wydanie) nie pozwala przewidzieć, kiedy system będzie ukończony

85 Literatura K. Beck: Extreme Programming Explained, Addison- Wesley, 1999 Andrzej Jaszkiewicz: Inżynieria oprogramowania, Helion, 1997 Wykłady z inżynierii oprogramowania: