SWOBODNE METODYKI PROJEKTOWANIA SI

Prezentacja na temat: "SWOBODNE METODYKI PROJEKTOWANIA SI"— Zapis prezentacji:

1 SWOBODNE METODYKI PROJEKTOWANIA SI
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 Specyfika swobodnych metodologii
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 specyfikacja konfiguracji: 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 FDD FUTURE DRIVEN DEVELOPMENT
METODOLOGIE ZWINNE FDD FUTURE 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 SCRUM Taktyka 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 XP Extreme Programming
METODOLOGIE ZWINNE XP Extreme 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ń

51 XP – etapy powstania wersji

52 Dziękuję za uwagę.