SWOBODNE METODYKI PROJEKTOWANIA SI

1
SWOBODNE METODYKI PROJEKTOWANIA SI
Politechnika warszawska 2008

• agile software development methods-
  charakterystyka, przeglad, zasadnosc uzycia

Maciej Socha Prowadzacy dr G. Protaziuk
2
PLAN PREZENTACJI

• Wprowadzenie
• Cykl zycia systemu zgodny z IOP
• Metody tworzenia SI zgodne z IOP
• Ryzyko tradycyjnych metod
• Specyfika swobodnych metodologii
• Manifest swobodnych metodyk
• Przeglad metodologii
• FDD
• SCRUM
• XP

3
Cykl zycia zgodny z IOP

• 1. Inicjalizacja systemu i wstepne
  planowanieZnalezienie potencjalnego obszaru
  zastosowania systemu informatycznego, który
  wspomoze lub zastapi dotychczasowe metody
  przetwarzania informacji.
• 2. Analiza wymagan i specyfikacja
  wymaganIdentyfikacja problemów, które nowy
  system informacyjny ma rozwiazac. Zarysowanie
  wlasciwosci operacyjnych systemu, wydajnosci i
  zasobów sprzetowych niezbednych do uzytkowania i
  konserwowania systemu.
• 3. Specyfikacja funkcjonalna i prototypowanie
  Identyfikacja i formalizacja obiektów obliczen,
  ich atrybutów i zaleznosci. Specyfikacja
  transformacji, którym obiekty beda podlegac.
• 4. Dekompozycja problemu Podzial systemu na
  logiczne podsystemy na podstawie wymagan i
  specyfikacji. Analiza logicznych podsystemów pod
  katem uzycia juz istniejacych komponentów
  informatycznych. Selekcja rozwiazan wykonac
  samodzielnie, kupic, wykorzystac juz istniejace.

4
Cykl zycia zgodny z IOP cd.

• 5. Projekt architekturalny i specyfikacja
  konfiguracji Okreslenie zaleznosci pomiedzy
  podsystemami, komponentami i modulami w sposób
  uwzgledniajacy szczególy ich budowy i wymagania
  wobec nich.
• 6. Szczególowe projektowanie i specyfikacja
  komponentów Opracowanie i kodyfikowanie metod
  przetwarzania informacji w komponentach
• 7. Implementacja komponentów i usuwanie bledów
  Wytwarzanie kodu zródlowego komponentów na
  podstawie uprzednich specyfikacji. Testowanie
  podstawowych funkcji komponentów.
• 8. Asemblacja systemu i testowanie Weryfikacja
  komponentów pod katem kompletnosci i zgodnosci
  ze specyfikacja. Asemblacja produktu z
  komponentów, weryfikacja wydajnosci podsystemów
  systemu jako calosci.

5
Cykl zycia zgodny z IOP cd.

• 9. Przeglad dokumentacji i dostarczenie systemu
  Opracowywanie i systematyzowanie dokumentacji
  powstalej w trakcie prowadzenia projektu pod
  katem raportów dla odbiorcy.
• 10. Opracowanie procedur instalacyjnych i
  instalacja Opracowanie dokumentacji
  instalacyjnej opisujacej sposób instalacji
  systemu.
• 11. Szkolenie dla uzytkowników Zapoznanie
  uzytkowników z systemem. Zapoznanie ich z
  mozliwosciami i ograniczeniami systemu.
• 12. Uzytkowanie i konserwacja oprogramowania
  Uzytkowanie, usuwanie bledów dostrzezonych w
  trakcie uzytkowania, rozbudowywanie systemu o
  nowe wlasciwosci, poprawa wydajnosci 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 zaliczajace sie do luki poznawczej,
  nie sa w trakcie analizy dostrzegane i nie
  zostana wyczerpujaco opracowane, mozna wiec
  okreslac je mianem ryzykownych punktów projektu.
• Od ogólu do szczególu
• Na tym poziomie pojawiajace sie problemy umykaja
  z powodu natloku szczególów w projekcie
• Od szczególu do ogólu
• Problemy staja sie zbyt ogólne dla zespolów
  zajmujacych sie zagadnieniami podstawowymi

8
Idee metodyk

• Tradycyjne metody prowadzenia projektu maja w
  zamysle sprzedac produkt gotowe oprogramowanie
• Realizacja produktu dla klienta
• Sukces dobrze wynegocjowany kontrakt
• Bardzo sformalizowany cykl zycia produktu
• Nowe techniki zarzadzania projektem ukierunkowane
  sa na usluge.
• Realizacja produktu dla i przy pomocy klienta
• Czlowiek uzytkownik, jako czynnik sukcesu.
• Elastyczne traktowanie planu realizacji.

9
Specyfika swobodnych metodyk

• Techniki zakladaja scisla wspólprace z
  uzytkownikiem czy odbiorca. Wlasciwie postuluje
  sie wlaczenie uzytkownika w proces projektowania
  oprogramowania.
• Sprzedawana jest usluga tworzenia oprogramowania
  a nie gotowy produkt -oprogramowanie, tak wiec
  uzytkownik jest tym, kto podejmuje decyzje co i w
  jakiej kolejnosci bedzie w projekcie wykonywane.
• Istotna wage przywiazuje sie do poprawnego
  szacowania kosztów prac, tak by
  inwestor/uzytkownik mógl swiadomie planowac swe
  wydatki na rozwój oprogramowania.

10
Specyfika swobodnych metodyk cd.

• Zobowiazuje sie wytwórce oprogramowania do tego,
  ze kazdym swym dzialaniem powinien udowadniac
  inwestorowi efektywne wykorzystanie czasu i
  powierzonych mu srodków.
• Sprzedajac usluge programowania rezygnuje sie z
  zysków z ponownego uzycia kodu i modeli
  analitycznych, bo prace odniesione sa do
  niepowtarzalnego projektu. Przy takim zalozeniu
  rozlegla dokumentacja projektowa staje sie
  zbednym kosztem obciazajacym uzytkownika i unika
  sie jej.
• Uproszczenia dokumentacyjne wymuszaja specyficzny
  sposób porozumiewania sie z uzytkownikiem. W
  trakcie tworzenia oprogramowania czesto (na
  biezaco) zadaje sie mu pytania i prosby o
  potwierdzenie dotyczace niewielkiego zakresu
  funkcjonalnosci. Stad wynikaja inkrementalny
  sposób dostarczania oprogramowania oraz krótkie
  iteracje implementacyjne.

11
Specyfika swobodnych metodyk cd.

• Nie specyfikuje sie formalnych punktów
  kontrolnych w projekcie - nie sa one potrzebne,
  gdyz zakonczenie kazdej iteracji jest punktem
  kontrolnym samym w sobie. Z drugiej strony
  wprowadzenie sformalizowanych punktów kontrolnych
  nie we wszystkich technikach jest mozliwe.
• Sekwencyjna realizacja wymagan uzytkownika
  powoduje czeste zmiany w architekturze systemu i
  koniecznosc przebudowy kodu. W nowych metodykach
  zadanie przebudowy kodu postrzega sie nie jako
  wyjatek, lecz jako regule.

12
Manifest swobodnych metodyk

• ludzie, ich kontakty, zdolnosc do rozwiazywania
  problemów sa wazniejsze niz sztywne procedury i
  narzedzia zarzadzania,
• wynikiem projektu jest pracujace oprogramowanie a
  nie dokumentacja,
• z uzytkownikiem sie wspólpracuje a nie negocjuje
  kontrakt,
• wazniejsza jest umiejetnosc reagowania na
  zmieniajace sie warunki otoczenia niz podazanie
  za opracowanym na wstepie planem.

13
METODOLOGIE ZWINNE

• FDDFUTURE DRIVEN DEVELOPMENT

14
FDD - charakterystyka

• metodyka tworzenia oprogramowania, wspomagajaca
  zarzadzanie fazami analiz, projektowania i
  konstrukcji oprogramowania
• jest projektowaniem zorientowanym na wlasciwosci
• prace rozpoczynaja sie od okreslenia ogólnego
  modelu systemu.
• okreslana jest domena projektu i iteracyjnie
  dzielona na coraz to mniejsze znaczeniowo
  obszary.
• kazdy niepodzielny obszar znaczeniowy jest
  opracowywany przez przypisana do niego grupe
  projektantów, w wyniku czego powstaje model
  szczególowy, bedacy skladnikiem calosciowego
  modelu systemu.
• zespól projektantów korzysta z opracowanych
  wczesniej wymagan systemowych i przypadków
  uzycia.

15
FDD dobre praktyki IOP

• oparcie procesu o wymagania klienta
• architektura systemu
• krótkie iteracje
• indywidualna odpowiedzialnosc za kod
• inspekcje

16
FDD pojecie cechy

• Zasadniczym elementem procesu FDD jest cecha
  (feature) produktu.
• Cecha jest maly fragment funkcjonalnosci
  produktu.
• Cecha w SI dostarcza klientowi interesujace go
  wyniki.
• Opisuje wymagania funkcjonalne wg
  schematu ltactiongttheltresultgtltbyoftofromfor
  gta(n)ltobjectgt
• Grupuje sie w zbiory cech wg schematu ltactiongt
  -ingltbuisness deliverablegtltbyoftofromforgta(n)lt
  objectgt

17
FDD role w zespole

• Menadzer projektu
• Eksperci dziedzinowi
• Glówny architekt
• Menadzer programistów
• Glówni programisci
• Wlasciciele klas

18
FDD realizacja metody

• zalozeniem jest inkrementacyjne opracowywanie
  poszczególnych funkcjonalnosci systemu
• projekt w mysl FDD sklada sie z pieciu
  sekwencyjnie nastepujacych etapów.

19
FDD faza I

• stworzenia zespolu projektowego pod kierownictwem
  Glównego Architekta,
• przeprowadzenia przegladu dziedziny problemu,
• studiowanie dokumentów z wymaganiami i z
  dziedziny problemu,
• przygotowanie alternatywnych modeli w oddzielnych
  malych grupach projektowych,
• wypracowanie wspólnego modelu,
• Zatwierdzenie ogólnego modelu,
• Zdokumentowanie istotnych zalozen dotyczacych
  projektu i alternatywnych rozwiazan.

20
FDD faza II

• na podstawie specyfikacji wymagan systemowych
  oraz opracowanego modelu/modeli opracowywanie sa
  list funkcjonalnosci
• Listy maja charakter hierarchiczny i zawieraja
  funkcjonalnosci glówne
• Rozdrabnianie funkcjonalnosci na coraz nizsze
  poziomy
• Przegladanie list przez uzytkowników i inwestorów
  w celu kontroli poprawnosci i kompletnosci

21
FDD faza III

• sformowania zespolu planujacego
• okreslenia kolejnosci implementacji
• przypisania zbioru cech glównym programistom
• przypisania klas do programistów

22
FDD faza IV

• sformowania zespolu programistów pod kierunkiem
  Glównego Programisty.
• opcjonalnego przegladu dziedziny problemu i
  studiowania dokumentów referencyjnych
• stworzenia diagramów sekwencji
• uszczególowienia modelu obiektowego
• zapisania nagló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 Mlyna

25
SCRUM - charakterystyka

• Istota metody Scrum jest adaptacyjny,
  samoorganizujacy sie proces wytwarzania
  oprogramowania.
• Zaklada ewolucyjny styl tworzenia oprogramowania.
• Koncentrujac sie na zadaniach zarzadzania
  pozostawia wolny wybór w wyborze technik
  prowadzenia prac programistycznych.
• Ewolucyjny styl to generalnie iteracja, a
  pojedynczy cykl to w istocie podprojekt kaskadowy
  skladajacy sie z opracowania wymagan, analizy,
  projektowania, kodowania i wdrozenia trwajacy nie
  dluzej niz 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 stwarzajace problemy w pracy
  zespolu
• Zapewnia zgodnosc pracy nad projektem z celami
  biznesowymi klienta
• Zapewnia zdazanie do celu
• Reprezentuje zespól

28
Product Owner

• Gwarant prac we wlasciwym kierunku
• Zajmuje sie
• Tworzeniem wymagan uzytownika (User stories)
• Nadawaniem priorytetów dla wymagan
• Budowaniem rejestru wymagan (Product Backlog)

29
SCRUM realizacja metody

• rozpoczecie gry (pregame),
• faza produkcji (development phase),
• gra na zakonczenie (postgame).

30
SCRUM - zarzadzanie

• Rozpoczecie prac zwiazane jest ze Spotkaniem
  Planowania Cyklu (Sprint planning meeting),
• Zakonczenie prac z nieformalnym Spotkaniem
  Przegladowym (Scrum Review meeting).
• Sa równiez Codzienne Spotkania Zespolu
  projektantów i programistów (Daily Scrum meeting).

31
SCRUM - kontrola

• Scrum przewiduje czeste dzialania zarzadcze
  skupiajace sie na identyfikowaniu problemów i
  przeszkód w pracach inzynieryjnych
• Biezaca samokontrola calego zespolu, codzienne
  spotkania, (Daily scrum meeting) 15 minut,
• Co robilem wczoraj?
• Co bede robil dzisiaj?
• Co mi przeszkadza w pracy?
• W trakcie spotkania omawiane sa problemy oraz
  planowane sa posuniecia z nich wynikajace.

32
SCRUM planowanie cyklu

• Spotkanie poprzedzajace rozpoczecie cyklu
  organizacja dzialan.
• Zdejmowanie cech z rejestru zadan.
• Stworzenie rejestru zadan przebiegu.
• Obejmuje wszystkich czlonków zespolu (prosiaki i
  kurczaki).
• Chicken okreslaja cel przebiegu.
• Pig uscislaja rejestr zgodnie z okreslonym celem.

33
SCRUM - dokumentacja

• Rejestr zadan (Product backlog)
• Historyjki klienta (User stories)
• Must be
• Should be
• Nice to have
• Rejestr zadan przebiegu (Sprint product backlog)
• Wykres spalania (Burn down) wykres
  pracochlonnosci

34
SCRUM tworzenie rejestru przebiegu

• rozbicie zyczen klienta, na elementarne czynnosci
  techniczne, konieczne do realizacji analizowanego
  celu
• oszacowanie kazdej czynnosci technicznej na koszt
  roboto-godziny potrzebnej do zrealizowania
  funkcjonalnosci
• przyporzadkowanie odpowiednich czynnosci do
  realizacji osobom najbardziej kompetentnym do jej
  wykonania, co ustala sam zespól, nie kierownik,
• zsumowanie wszystkich roboto-godzin z wszystkich
  wybranych czynnosci i sprawdzeniu czy laczna ich
  liczba przekracza, czy nie zapelnia godzin
  jednego pelnego cyklu,
• dopelnienie lub ujecie wybranych czynnosci, aby
  mozliwie jak najdokladniej zmiescic sie czasowo w
  przebiegu jednego cyklu, czyli 30 dni.

35
SCRUM - pregame

• obejmuje czynnosci planowania i opracowania
  zarysu architektury systemu.
• W trakcie tej fazy wszystkie znane wymagania sa
  spisywane i opracowywana jest lista wymagan
  (Product backlog).
• Zródlem wymagan sa przede wszystkim uzytkownicy,
  ale równiez dzial marketingu i sprzedazy, dzial
  obslugi klienta oraz sam zespól
  projektantów-programistów.
• Wymaganiom zestawionym na liscie przypisywane sa
  priorytety.
• Na podstawie listy opracowywana jest architektura
  systemu.
• Finalnie, w ramach oddzielnego spotkania,
  tworzony jest podzbiór listy wymagan.
• Ustalany jest cel przebiegu.

36
SCRUM faza produkcji

• (Product backlog). Lista ta jest otwarta, a
  zadania do realizacji dopisywane sa do niej w
  trakcie calego procesu tworzenia oprogramowania.
• (sprint backlog list). Zawarte tam wymagania sa
  realizowane w ramach aktualnej iteracji
• Rozpatrywane sa zmiany w architekturze systemu
  wynikle z wprowadzenia nowych wymagan.
• Kontrola procesu wytwórczego estymacja wykresu
  pracochlonnosci

37
SCRUM - pracochlonnosc

• Proces estymacji pracochlonnosci polega na
  gromadzeniu informacji statystycznych o
  przebiegu projektu i wyznaczaniu kosztu prac na
  ich podstawie.
• Kazdego dnia aktualizowana jest pozostala do
  realizacji liczba robotogodzin
• Aproksymacja pokazuje przyblizony termin
  zakonczenia przebiegu w odniesieniu do
  osiagnietego tempa prac
• Na jego podstawie aktualizuje sie rejestr
  przebiegu.

38
SCRUM - przebieg
39
SCRUM postgame

• rozpoczyna sie wraz z ustaleniem pomiedzy
  uzytkownikiem a projektantami, ze wymagania sa
  zrealizowane (lista wymagan jest pusta).
• System jest przygotowany do instalacji.
• W tej fazie wykonywana jest ostateczna integracja
  modulów i testowanie, a takze przygotowuje sie
  dokumentacje.
• Spotkanie podsumowujace (Scrum Review Meeting)
• Omawiane sa na nim postepy prac oraz formulowane
  sa wnioski, nowe wpisy do listy wymagan lub
  postulowane sa generalne zmiany w architekturze
  systemu.

40
METODOLOGIE ZWINNE

• XPExtreme Programming

41
XP - charakterystyka

• Ewolucyjne podejscie do projektowania i
  programowania
• Praktyka bardzo krótkich cyklów wytwarzania
  oprogramowania zmuszajaca do szybkich odpowiedzi
  klienta
• Ciagle zainteresowanie pracami klienta
• Ekstremalnie scisla wspólpraca z klientem
• nie ma uniwersalnej metody prowadzenia projektu
  informatycznego.
• praktyki XP powinny byc przystosowywane do
  aktualnych potrzeb i specyfiki projektu.

42
XP cykl zycia projektu

• eksploracji,
• planowania,
• iteracji wykonawczych,
• przygotowania do produkcji,
• utrzymania w ruchu,
• zakonczenia projektu.

43
XP schemat cyklu zycia
44
XP faza eksploracji

• zespól projektowy zapoznaje sie z tematem prac i
  pozyskuje podstawowe informacje od uzytkownika.
• Uzytkownik przedstawia sposób uzytkowania systemu
  poprzez opowiadania (story),
• na podstawie historyjek budowany jest zarys
  architektury systemu
• budowana jest lista funkcjonalnosci.
• W tym czasie projektanci testuja wybrana
  technologie tworzac niezbedne prototypy oraz
  zapoznaja sie z uzywanymi narzedziami

45
XP faza planowania

• Opowiadania przedstawione przez uzytkownika sa
  analizowane i nadawane sa im priorytety.
• W porozumieniu z uzytkownikiem zestawiana jest
  lista funkcjonalnosci, które maja byc opracowane.
• Programisci oceniaja czas realizacji zadan i
  ustalany jest harmonogram prac i termin
  zakonczenia prac.

46
XP faza iteracji wykonawczych

• Sklada sie z jedno lub kilkutygodniowych mini
  cykli implementujacych kolejne wlasciwosci
  systemu.
• Wykonywane sa dzialania analityczne, projektowe,
  kodowanie i testowanie.
• Na koncu kazdego mini cyklu wykonywane sa testy
  oprogramowania zaplanowane przez uzytkownika.

47
XP faza przygotowania do produkcji

• W tej fazie system zawierajacy uzgodniona porcje
  funkcjonalnosci jest przygotowywany do wdrozenia.
  
• Pojawiajace sie uwagi uzytkownika sa
  implementowane lub przeznaczane do implementacji
  w nastepnej wersji oprogramowania.
• Wykonywane sa dodatkowe gruntowne testy.

48
XP faza konserwacji

• Uzytkownik jest wyposazony w dzialajaca wersje
  oprogramowania, która wymaga opieki i nadzoru.
• Zespól projektowy w tym samym czasie wykonuje
  kolejna wersje oprogramowania.
• W trakcie pracy z oprogramowaniem odbiorca
  formuluje kolejne postulaty dla zespolu
  projektowego.
• Wysilek poswiecany na utrzymanie w ruchu wersji
  produkcyjnej wplywa na zmniejszenie predkosci
  opracowywania nowej wersji oprogramowania.

49
XP zakonczenie projektu

• Gdy uzytkownik nie jest juz zainteresowany
  dodawaniem funkcjonalnosci do oprogramowania,
  tempo wspólpracy z uzytkownikiem spada,
  formulowane wnioski o rozszerzenie
  funkcjonalnosci maja charakter drugorzedny i
  czesto nie sa wdrazane z powodów ekonomicznych.
• W tej fazie zespól projektowy podejmuje decyzje
  o zakonczeniu projektu, blokuje zmiany w
  architekturze systemu i kodzie zródlowym,
  opracowuje dokumentacje systemu i projektu,
  ostateczne wersje instrukcji uzytkownika oraz
  instrukcje konserwacji.

50
XP - praktyki

• Programowanie parami
• Ciagle testowanie
• Ciagle planowanie
• Ciagle integrowanie
• Refactoring kodu
• Utrzymywanie standardu kodowania
• Zbiorowa wlasnosc kodu
• Prostota rozwiazan

51
XP etapy powstania wersji
52
Dziekuje za uwage.