SWOBODNE METODYKI PROJEKTOWANIA SI

1. Politechnika warszawska 2008 SWOBODNE METODYKI PROJEKTOWANIA SI „agile software development methods”- charakterystyka, przegląd, zasadność użycia Maciej Socha Prowadzący: dr G. Protaziuk

2. PLAN PREZENTACJI • Wprowadzenie • Cykl życia systemu zgodny z IOP • Metody tworzenia SI zgodne z IOP • Ryzyko tradycyjnych metod • Specyfika swobodnych metodologii • Manifest swobodnych metodyk • Przegląd metodologii • FDD • SCRUM • XP

3. Cykl życia zgodny z IOP 1. Inicjalizacja systemu i wstępne planowanie:Znalezienie potencjalnego obszaru zastosowania systemu informatycznego, który wspomoże lub zastąpi dotychczasowe metody przetwarzania informacji. 2. Analiza wymagań i specyfikacja wymagań:Identyfikacja problemów, które nowy system informacyjny ma rozwiązać. Zarysowanie właściwości operacyjnych systemu, wydajności i zasobów sprzętowych niezbędnych do użytkowania i konserwowania systemu. 3. Specyfikacja funkcjonalna i prototypowanie: Identyfikacja i formalizacja obiektów obliczeń, ich atrybutów i zależności. Specyfikacja transformacji, którym obiekty będą podlegać. 4. Dekompozycja problemu: Podział systemu na logiczne podsystemy na podstawie wymagań i specyfikacji. Analiza logicznych podsystemów pod kątem użycia już istniejących komponentów informatycznych. Selekcja rozwiązań: wykonać samodzielnie, kupić, wykorzystać już istniejące.

4. Cykl życia zgodny z IOP cd. 5. Projekt architekturalny i specyfikacjakonfiguracji:Określenie zależności pomiędzy podsystemami, komponentami i modułami w sposób uwzględniający szczegóły ich budowy i wymagania wobec nich. 6. Szczegółowe projektowanie i specyfikacja komponentów: Opracowanie i kodyfikowanie metod przetwarzania informacji w komponentach 7. Implementacja komponentów i usuwanie błędów: Wytwarzanie kodu źródłowego komponentów na podstawie uprzednich specyfikacji. Testowanie podstawowych funkcji komponentów. 8. Asemblacja systemu i testowanie: Weryfikacja komponentów pod kątem kompletności i zgodności ze specyfikacją. Asemblacja produktu z komponentów, weryfikacja wydajności podsystemów systemu jako całości.

5. Cykl życia zgodny z IOP cd. 9. Przegląd dokumentacji i dostarczenie systemu: Opracowywanie i systematyzowanie dokumentacji powstałej w trakcie prowadzenia projektu pod kątem raportów dla odbiorcy. 10. Opracowanie procedur instalacyjnych i instalacja: Opracowanie dokumentacji instalacyjnej opisującej sposób instalacji systemu. 11. Szkolenie dla użytkowników: Zapoznanie użytkowników z systemem. Zapoznanie ich z możliwościami i ograniczeniami systemu. 12. Użytkowanie i konserwacja oprogramowania:Użytkowanie, usuwanie błędów dostrzeżonych w trakcie użytkowania, rozbudowywanie systemu o nowe właściwości, poprawa wydajności systemu.

6. Metody tworzenia SI zgodne z IOP • Model kaskadowy • Model przyrostowy • Model spiralny • Model komponentowy • Model formalnego konstruowania • Model prototypowania

7. Ryzyko stosowania metod IOP • Luka formalna w dziedzinie poznania • Zagadnienia zaliczające się do luki poznawczej, nie są w trakcie analizy dostrzegane i nie zostaną wyczerpująco opracowane, można więc określać je mianem ryzykownych punktów projektu. • Od ogółu do szczegółu • Na tym poziomie pojawiające się problemy umykają z powodu natłoku szczegółów w projekcie • Od szczegółu do ogółu • Problemy stają się zbyt ogólne dla zespołów zajmujących się zagadnieniami podstawowymi

8. Idee metodyk: • Tradycyjne metody prowadzenia projektu mają w zamyśle sprzedać produkt – gotowe oprogramowanie • Realizacja produktu dla klienta • Sukces – dobrze wynegocjowany kontrakt • Bardzo sformalizowany cykl życia produktu • Nowe techniki zarządzania projektem ukierunkowane są na usługę. • Realizacja produktu dla i przy pomocy klienta • Człowiek – użytkownik, jako czynnik sukcesu. • Elastyczne traktowanie planu realizacji.

9. Specyfika swobodnych metodyk • Techniki zakładają ścisłą współpracę z użytkownikiem czy odbiorcą. Właściwie postuluje się włączenie użytkownika w proces projektowania oprogramowania. • Sprzedawana jest usługa tworzenia oprogramowania a nie gotowy produkt -oprogramowanie, tak więc użytkownik jest tym, kto podejmuje decyzje co i w jakiej kolejności będzie w projekcie wykonywane. • Istotną wagę przywiązuje się do poprawnego szacowania kosztów prac, tak by inwestor/użytkownik mógł świadomie planować swe wydatki na rozwój oprogramowania.

10. Specyfika swobodnych metodyk cd. • Zobowiązuje się wytwórcę oprogramowania do tego,że każdym swym działaniem powinien udowadniać inwestorowi efektywne wykorzystanie czasu i powierzonych mu środków. • Sprzedając usługę programowania rezygnuje się z zysków z ponownego użycia kodu i modeli analitycznych, bo prace odniesione są do niepowtarzalnego projektu. Przy takim założeniu rozległa dokumentacja projektowa staje się zbędnym kosztem obciążającym użytkownika i unika się jej. • Uproszczenia dokumentacyjne wymuszają specyficzny sposób porozumiewania się z użytkownikiem. W trakcie tworzenia oprogramowania często (na bieżąco) zadaje się mu pytania i prośby o potwierdzenie dotyczące niewielkiego zakresu funkcjonalności. Stąd wynikają inkrementalny sposób dostarczania oprogramowania oraz krótkie iteracje implementacyjne.

11. Specyfika swobodnych metodyk cd. • Nie specyfikuje się formalnych punktów kontrolnych w projekcie - nie są one potrzebne, gdyż zakończenie każdej iteracji jest punktem kontrolnym samym w sobie. Z drugiej strony wprowadzenie sformalizowanych punktów kontrolnych nie we wszystkich technikach jest możliwe. • Sekwencyjna realizacja wymagań użytkownika powoduje częste zmiany w architekturze systemu i konieczność przebudowy kodu. W nowych metodykach zadanie przebudowy kodu postrzega się nie jako wyjątek, lecz jako regułę.

12. Manifest swobodnych metodyk • ludzie, ich kontakty, zdolność do rozwiązywania problemów są ważniejsze niż sztywne procedury i narzędzia zarządzania, • wynikiem projektu jest pracujące oprogramowanie a nie dokumentacja, • z użytkownikiem się współpracuje a nie negocjuje kontrakt, • ważniejsza jest umiejętność reagowania na zmieniające się warunki otoczenia niż podążanie za opracowanym na wstępie planem.

13. METODOLOGIE ZWINNE FDDFUTURE DRIVEN DEVELOPMENT

14. FDD - charakterystyka • metodyka tworzenia oprogramowania, wspomagająca zarządzanie fazami analiz, projektowania i konstrukcji oprogramowania • jest projektowaniem zorientowanym na właściwości • prace rozpoczynają się od określenia „ogólnego modelu systemu”. • określana jest domena projektu i iteracyjnie dzielona na coraz to mniejsze znaczeniowo obszary. • każdy niepodzielny obszar znaczeniowy jest opracowywany przez przypisaną do niego grupę projektantów, w wyniku czego powstaje model szczegółowy, będący składnikiem całościowego modelu systemu. • zespół projektantów korzysta z opracowanych wcześniej wymagań systemowych i przypadków użycia.

15. FDD – dobre praktyki IOP • oparcie procesu o wymagania klienta • architektura systemu • krótkie iteracje • indywidualna odpowiedzialność za kod • inspekcje

16. FDD – pojęcie cechy • Zasadniczym elementem procesu FDD jest cecha (feature) produktu. • Cechą jest mały fragment funkcjonalności produktu. • Cecha w SI dostarcza klientowi interesujące go wyniki. • Opisuje wymagania funkcjonalne wg schematu:<action>the<result><by|of|to|from|for>a(n)<object> • Grupuje się w zbiory cech wg schematu:<action>-ing<buisness deliverable><by|of|to|from|for>a(n)<object>

17. FDD – role w zespole • Menadżer projektu • Eksperci dziedzinowi • Główny architekt • Menadżer programistów • Główni programiści • Właściciele klas

18. FDD – realizacja metody • założeniem jest inkrementacyjne opracowywanie poszczególnych funkcjonalności systemu • projekt w myśl FDD składa się z pięciu sekwencyjnie następujących etapów.

19. FDD – faza I • stworzenia zespołu projektowego pod kierownictwem Głównego Architekta, • przeprowadzenia przeglądu dziedziny problemu, • studiowanie dokumentów z wymaganiami i z dziedziny problemu, • przygotowanie alternatywnych modeli w oddzielnych małych grupach projektowych, • wypracowanie wspólnego modelu, • Zatwierdzenie ogólnego modelu, • Zdokumentowanie istotnych założeń dotyczących projektu i alternatywnych rozwiązań.

20. FDD – faza II • na podstawie specyfikacji wymagań systemowych oraz opracowanego modelu/modeli opracowywanie są list funkcjonalności • Listy mają charakter hierarchiczny i zawierają funkcjonalności główne • Rozdrabnianie funkcjonalności na coraz niższe poziomy • Przeglądanie list przez użytkowników i inwestorów w celu kontroli poprawności i kompletności

21. FDD – faza III • sformowania zespołu planującego • określenia kolejności implementacji • przypisania zbioru cech głównym programistom • przypisania klas do programistów

22. FDD – faza IV • sformowania zespołu programistów pod kierunkiem Głównego Programisty. • opcjonalnego przeglądu dziedziny problemu i studiowania dokumentów referencyjnych • stworzenia diagramów sekwencji • uszczegółowienia modelu obiektowego • zapisania nagłówków klas i metod • inspekcji projektu

23. FDD - faza V • implementacja kodu klas • przeprowadzenia inspekcji kodu • testowania jednostkowego • integracji nowego kodu z produktem

24. METODOLOGIE ZWINNE SCRUMTaktyka Młyna

25. SCRUM - charakterystyka • Istotą metody Scrum jest adaptacyjny, samoorganizujący się proces wytwarzania oprogramowania. • Zakłada ewolucyjny styl tworzenia oprogramowania. • Koncentrując się na zadaniach zarządzania pozostawia wolny wybór w wyborze technik prowadzenia prac programistycznych. • Ewolucyjny styl to generalnie iteracja, a pojedynczy cykl to w istocie podprojekt kaskadowy składający się z opracowania wymagań, analizy, projektowania, kodowania i wdrożenia trwający nie dłużej niż 30 dni.

26. ROLE „Pig” i „Chicken” • Produkt Owner • Scrum Master • The Team • Users • Klient • Managers

27. Scrum Master • Nie jest liderem, • Nie planuje, • Nie kontroluje, • Nie przydziela • Usuwa przeszkody stwarzające problemy w pracy zespołu • Zapewnia zgodność pracy nad projektem z celami biznesowymi klienta • Zapewnia zdążanie do celu • Reprezentuje zespół

28. Product Owner • Gwarant prac we właściwym kierunku • Zajmuje się: • Tworzeniem wymagań użytownika (User stories) • Nadawaniem priorytetów dla wymagań • Budowaniem rejestru wymagań (Product Backlog)

29. SCRUM – realizacja metody • rozpoczęcie gry (pregame), • faza produkcji (development phase), • gra na zakończenie (postgame).

30. SCRUM - zarządzanie • Rozpoczęcie prac związane jest ze Spotkaniem Planowania Cyklu (Sprint planning meeting), • Zakończenie prac z nieformalnym Spotkaniem Przeglądowym (Scrum Review meeting). • Są również Codzienne Spotkania Zespołu projektantów i programistów (Daily Scrum meeting).

31. SCRUM - kontrola • Scrum przewiduje częste działania zarządcze skupiające się na identyfikowaniu problemów i przeszkód w pracach inżynieryjnych • Bieżąca samokontrola całego zespołu, codzienne spotkania, (Daily scrum meeting) 15 minut, • Co robiłem wczoraj? • Co będę robił dzisiaj? • Co mi przeszkadza w pracy? • W trakcie spotkania omawiane są problemy oraz planowane są posunięcia z nich wynikające.

32. SCRUM – planowanie cyklu • Spotkanie poprzedzające rozpoczęcie cyklu – organizacja działań. • Zdejmowanie cech z rejestru zadań. • Stworzenie rejestru zadań przebiegu. • Obejmuje wszystkich członków zespołu (prosiaki i kurczaki). • Chicken określają cel przebiegu. • Pig uściślają rejestr zgodnie z określonym celem.

33. SCRUM - dokumentacja • Rejestr zadań (Product backlog) • Historyjki klienta (User stories) • Must be • Should be • Nice to have • Rejestr zadań przebiegu (Sprint product backlog) • Wykres spalania (Burn down) – wykres pracochłonności

34. SCRUM – tworzenie rejestru przebiegu • rozbicieżyczeń klienta, na elementarne czynności techniczne, konieczne do realizacji analizowanego celu • oszacowanie każdej czynności technicznej na koszt roboto-godziny potrzebnej do zrealizowania funkcjonalności • przyporządkowanie odpowiednich czynności do realizacji osobom najbardziej kompetentnym do jej wykonania, co ustala sam zespół, nie kierownik, • zsumowanie wszystkich roboto-godzin z wszystkich wybranych czynności i sprawdzeniu czy łączna ich liczba przekracza, czy nie zapełnia godzin jednego pełnego cyklu, • dopełnienie lub ujecie wybranych czynności, aby możliwie jak najdokładniej zmieścić się czasowo w przebiegu jednego cyklu, czyli 30 dni.

35. SCRUM - pregame • obejmuje czynności planowania i opracowania zarysu architektury systemu. • W trakcie tej fazy wszystkie znane wymagania są spisywane i opracowywana jest lista wymagań (Product backlog). • Źródłem wymagań są przede wszystkim użytkownicy, ale również dział marketingu i sprzedaży, dział obsługi klienta oraz sam zespół projektantów-programistów. • Wymaganiom zestawionym na liście przypisywane są priorytety. • Na podstawie listy opracowywana jest architektura systemu. • Finalnie, w ramach oddzielnego spotkania, tworzony jest podzbiór listy wymagań. • Ustalany jest cel przebiegu.

36. SCRUM – faza produkcji • (Product backlog). Lista ta jest otwarta, a zadania do realizacji dopisywane są do niej w trakcie całego procesu tworzenia oprogramowania. • (sprint backlog list). Zawarte tam wymagania są realizowane w ramach aktualnej iteracji • Rozpatrywane są zmiany w architekturze systemu wynikłe z wprowadzenia nowych wymagań. • Kontrola procesu wytwórczego estymacją wykresu pracochłonności

37. SCRUM - pracochłonność • Proces estymacji pracochłonności polega na gromadzeniu informacji statystycznych o przebiegu projektu i wyznaczaniu kosztu prac na ich podstawie. • Każdego dnia aktualizowana jest pozostała do realizacji liczba robotogodzin • Aproksymacja pokazuje przybliżony termin zakończenia przebiegu w odniesieniu do osiągniętego tempa prac • Na jego podstawie aktualizuje się rejestr przebiegu.

38. SCRUM - przebieg

39. SCRUM – postgame • rozpoczyna się wraz z ustaleniem pomiędzy użytkownikiem a projektantami, że wymagania są zrealizowane (lista wymagań jest pusta). • System jest przygotowany do instalacji. • W tej fazie wykonywana jest ostateczna integracja modułów i testowanie, a także przygotowuje się dokumentację. • Spotkanie podsumowujące (Scrum Review Meeting) • Omawiane są na nim postępy prac oraz formułowane są wnioski, nowe wpisy do listy wymagań lub postulowane są generalne zmiany w architekturze systemu.

40. METODOLOGIE ZWINNE XPExtreme Programming

41. XP - charakterystyka • Ewolucyjne podejście do projektowania i programowania • Praktyka bardzo krótkich cyklów wytwarzania oprogramowania zmuszająca do szybkich odpowiedzi klienta • Ciągłe zainteresowanie pracami klienta • Ekstremalnie ścisła współpraca z klientem • nie ma uniwersalnej metody prowadzenia projektu informatycznego. • praktyki XP powinny być przystosowywane do aktualnych potrzeb i specyfiki projektu.

42. XP – cykl życia projektu • eksploracji, • planowania, • iteracji wykonawczych, • przygotowania do produkcji, • utrzymania w ruchu, • zakończenia projektu.

43. XP – schemat cyklu życia

44. XP – faza eksploracji • zespół projektowy zapoznaje się z tematem prac i pozyskuje podstawowe informacje od użytkownika. • Użytkownik przedstawia sposób użytkowania systemu poprzez opowiadania („story”), • na podstawie historyjek budowany jest zarys architektury systemu • budowana jest lista funkcjonalności. • W tym czasie projektanci testują wybraną technologię tworząc niezbędne prototypy oraz zapoznają się z używanymi narzędziami

45. XP – faza planowania • Opowiadania przedstawione przez użytkownika są analizowane i nadawane są im priorytety. • W porozumieniu z użytkownikiem zestawiana jest lista funkcjonalności, które mają być opracowane. • Programiści oceniają czas realizacji zadań i ustalany jest harmonogram prac i termin zakończenia prac.

46. XP – faza iteracji wykonawczych • Składa się z jedno lub kilkutygodniowych mini cykli implementujących kolejne właściwości systemu. • Wykonywane są działania analityczne, projektowe, kodowanie i testowanie. • Na końcu każdego mini cyklu wykonywane są testy oprogramowania zaplanowane przez użytkownika.

47. XP – faza przygotowania do produkcji • W tej fazie system zawierający uzgodnioną porcję funkcjonalności jest przygotowywany do wdrożenia. • Pojawiające się uwagi użytkownika są implementowane lub przeznaczane do implementacji w następnej wersji oprogramowania. • Wykonywane są dodatkowe gruntowne testy.

48. XP – faza konserwacji • Użytkownik jest wyposażony w działającą wersję oprogramowania, która wymaga opieki i nadzoru. • Zespół projektowy w tym samym czasie wykonuje kolejną wersję oprogramowania. • W trakcie pracy z oprogramowaniem odbiorca formułuje kolejne postulaty dla zespołu projektowego. • Wysiłek poświęcany na utrzymanie w ruchu wersji produkcyjnej wpływa na zmniejszenie prędkości opracowywania nowej wersji oprogramowania.

49. XP – zakończenie projektu • Gdy użytkownik nie jest już zainteresowany dodawaniem funkcjonalności do oprogramowania, tempo współpracy z użytkownikiem spada, formułowane wnioski o rozszerzenie funkcjonalności mają charakter drugorzędny i często nie są wdrażane z powodów ekonomicznych. • W tej fazie zespół projektowy podejmuje decyzję o zakończeniu projektu, blokuje zmiany w architekturze systemu i kodzie źródłowym, opracowuje dokumentację systemu i projektu, ostateczne wersje instrukcji użytkownika oraz instrukcje konserwacji.

50. XP - praktyki • Programowanie parami • Ciagłe testowanie • Ciągłe planowanie • Ciągłe integrowanie • Refactoring kodu • Utrzymywanie standardu kodowania • Zbiorowa własność kodu • Prostota rozwiązań