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

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

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.

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.

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.

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

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

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.

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.

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.

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łę.

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.

FDD FUTURE DRIVEN DEVELOPMENT METODOLOGIE ZWINNE FDD FUTURE DRIVEN DEVELOPMENT

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.

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

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>

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

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.

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ń.

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

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

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

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

METODOLOGIE ZWINNE SCRUM Taktyka Młyna

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.

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

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ół

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)

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

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).

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.

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.

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

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.

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.

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

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.

SCRUM - przebieg

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.

XP Extreme Programming METODOLOGIE ZWINNE XP Extreme Programming

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.

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

XP – schemat cyklu życia

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

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.

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.

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.

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.

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.

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ń

XP – etapy powstania wersji

Dziękuję za uwagę.