Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


Prezentacja na temat: "SWOBODNE METODYKI PROJEKTOWANIA SI agile software development methods - charakterystyka, przegląd, zasadność użycia Maciej Socha Prowadzący: dr G. Protaziuk."— Zapis prezentacji:

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

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 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 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: the a(n) Grupuje się w zbiory cech wg schematu: -ing a(n)

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, 1. Co robiłem wczoraj? 2. Co będę robił dzisiaj? 3. 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 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ę.


Pobierz ppt "SWOBODNE METODYKI PROJEKTOWANIA SI agile software development methods - charakterystyka, przegląd, zasadność użycia Maciej Socha Prowadzący: dr G. Protaziuk."

Podobne prezentacje


Reklamy Google