Projektowanie oprogramowania systemów METODYKI PROJEKTOWE

Transkrypt

1 Projektowanie oprogramowania systemów METODYKI PROJEKTOWE

2 Unified Modeling Language UML jest językiem graficznym umożliwiającym wizualizację planów oprogramowania w postaci diagramów Diagramy UML reprezentują dwa widoki na model systemu Statyczny (strukturalny) widok z obiektami, atrybutami, operacjami i relacjami Dynamiczny (behawioralny) widok skupiający się na współpracy pomiędzy obiektami i zmianach stanu Diagramy UML to tylko widok (rzut) modelu; Model istnieje również bez diagramów, ale diagramy pozwalają go zwizualizować

3 diagram klas UML diagramów UML

4 diagramy strukturalne Koncentrują się na rzeczach, które muszą znajdować się w modelowanym systemie Wykorzystywane do dokumentowania architektury oprogramowania systemów Rodzaje diagram klas (class) diagram komponentów (component) diagram obiektów (object) composite structure diagram deployment diagram package diagram profile diagram

5 diagramy behawioralne Skupiają się na tym, co musi się wydarzyć w modelowanym systemie Używane do dokumentowania funkcjonalności systemu Rodzaje diagram aktywności (activity) diagramy interakcji (interaction) diagram maszyny stanów (state machine) diagram przypadków użycia (use case)

6 diagramy interakcji Podzbiór diagramów behawioralnych koncentrujący się na przepływie kontroli i danych pomiędzy podmiotami modelowanego systemu Rodzaje interaction overview diagram diagram sekwencji (sequence) timing diagram diagram komunikacji (communication)

7 diagram komponentów Pokazuje jak komponenty są ze sobą połączone tworząc większe komponenty

8 diagram klas Opisuje strukturę systemu, pokazując klasy, ich atrybuty, operacje i relacje między podmiotami Najpopularniejszy rodzaj diagramów UML Równocześnie, jeden z najbardziej złożonych

9 diagram aktywności Graficzne przedstawienie przepływu pracy (workflow) aktywności i akcji, obrazuje ogólny przepływ kontroli Podobny do typowych flow chartów /wykresów blokowych

10 diagram przypadków użycia Reprezentuje interakcje użytkownika z systemem

11 diagram sekwencji Pokazuje interakcje między podmiotami uszeregowane w skali czasu Związany z realizacją przypadków użycia

12 użycie UML Nie każdy system potrzebuje wszystkich diagramów UML Większość systemów w istocie potrzebuje tylko kilku Nie ma potrzeby specyfikowania wszystkich i każdego aspektu systemu; niektóre są oczywiste i/lub są realizacją znanych wzorców projektowych (design patterns); inne są zbyt niskopoziomowe szczegóły implementacyjne Użyj diagramu klas dla wyspecyfikowania najważniejszych/kluczowych hierarchii klas Użyj diagramu sekwencji dla wyspecyfikowania nieoczywistych interakcji (np. projekt protokołu komunikacyjnego) Użyj diagramu maszyny stanów do wyspecyfikowania stanów kluczowych obiektów i podsystemów Użyj diagramu przypadków użycia do wyspecyfikowania przypadków użycia Nade wszystko, używaj mózgu ;> podczas tworzenia diagramów i skoncentruj się na zagadnieniach ważnych i złożonych; redukuj złożoność zamiast ją generować UML jest językiem modelowania, nie tłumacz jego konstrukcji z języka angielskiego

13 narzędzia UML Poszukaj narzędzi z możliwością generowania kodu wprost z modeli interfejsu zaoszczędzisz sporo pracy JUDE (obecnie astah, free, Java) - Microsoft Visio do pobrania z DreamSpark Eclipse + EMF/GEF/UML2 (free) NetBeans Microsoft Visual Studio DreamSpark mnóstwo innych, ale tylko nieliczne darmowe implementują cały UML (większość diagramy klas + kilka innych)

14 plan Metodyki projektowe Scrum Cykl Zespół Prowadzenie projektu events Artefakty

15 Projekt - definicja Projekt (przedsięwzięcie) to unikatowy zestaw skoordynowanych działań ograniczony czasem i kosztami, mający na celu uzyskanie zbioru określonych uprzednio produktów (zakres spełniający cele projektu), zachowując przy tym normy jakości i wymagania. IPMA Ograniczony w czasie wysiłek, podjęty w celu wytworzenia unikatowego produktu, usługi lub rezultatu PMI Organizacja powołana na pewien czas w celu wytworzenia w przyjętym czasie oraz przy wykorzystaniu uprzednio określonych zasobów niepowtarzalnych, a wcześniej określonych wyników czy rezultatu. PRINCE2 Jednostkowy proces, składający się ze zbioru skoordynowanych działań i mający dokładnie określone daty rozpoczęcia oraz zakończenia; jest to przedsięwzięcie zmierzające do osiągnięcia założonego celu przy określonych ograniczeniach czasowych, kosztowych oraz zasobowych ISO 10006

16 Projekt jest unikalny, jest ograniczony w czasie, ma określony koszt i czas trwania, posiada cel.

17 S.M.A.R.T. S specific, szczegółowy, M measurable, mierzalny, A achievable, osiągalny, R realistic, realistyczny, T time bound, określony w czasie

18 Metodyka projektowa Ogół zasad w jaki sposób wykonać czynność realizacji projektu, aby osiągnąć sukces, Ogół narzędzi jakie powinno się wykorzystać do realizacji określonego celu projektowego Z wykorzystaniem metodyk są ustalane: Fazy projektu role uczestników projektu modele tworzone w każdej z faz; scenariusze postępowania w każdej z faz; reguły przechodzenia do kolejnej fazy; notacje, których należy używać; dokumentację powstającą w każdej z faz.

19 Podział

20 RUP (Rational Unified Process) Proces wytwarzania oprogramowania Zestaw wskazówek jak prowadzić projekt informatyczny Metodyka wykorzystuję model przyrostowy tworzenia oprogramowania W trakcie trwania projektu odbywa się ciągłe monitorowanie jakości produktu

21

22 Cykl RUP

23 PRINCE2 (PRojects IN Controlled Environments)

24 PRINCE2 Prince 2 jest oparta na podejściu procesowym, co oznacza, że określa co" i dlaczego", Planowanie oparte na produktach Sterowanie zmianami Przeglądy jakości

25 PRINCE2 - struktura organizacji

26 PRINCE2 - podejście procesowe do zarządzania projektem Strategiczne zarządzanie projektem (ZS) Directing a project (DP) Uruchamianie Projektu/Przygotowanie Założeń Projektu (PP) Starting up a project (SU) Inicjowanie projektu (IP) Initiating a project (IP) Sterowanie Etapem (SE) Controlling a stage (CS) Zarządzanie Wytwarzaniem Produktów (WP) Managing product delivery (MP) Zarządzanie Zakresem Etapu (ZE) Managing stage boundaries (SB) Zamykanie Projektu (ZP) Closing a project (CP)

27 PMBoK (Project Management Body of Knowledge)

28 PMBoK PMBoK jest międzynarodowym zbiorem dobrych praktyk w dziedzinie zarządzania projektami. Standard PMBoK został opracowany przez zrzeszenie PMI Project Management Institute, którego członkami są praktycy z zakresu zarządzania oraz gospodarki i biznesu. PMBoK składa się z 39 procesów, zgrupowanych w 5 zbiorach procesowych (PMI, 2013): grupa procesów rozpoczęcia, grupa procesów planowania, grupa procesów realizacji, grupa procesów monitorowania i kontroli, grupa procesów zakończenia.

29 PMBoK Poszczególne grupy procesów można rozumieć również jako kolejne etapy, które należy wykonać, aby wytworzyć określony produkt. Zgodnie z zasadą PMBOK poszczególne etapy posiadają swoje wejście i wyjście (PMI, 2013). Rezultat który jest produktem jednego procesu wchodzi na wejście kolejnego. W podobny sposób są wymieniane informacje pomiędzy kolejnymi grupami procesów. Pięcioetapowe rozróżnienie opisuję w sposób kompleksowy zwyczajowe podejście do prowadzenia projektów.

30

31 SCRUM Scrum jest metodyką zarządzania i kontroli, która skupia się na wytwarzaniu oprogramowanie, które spełnia potrzeby klienta. Sam Scrum posiada proste ramy dla skutecznej pracy zespołowej w szczególności w przypadku złożonych projektów informatycznych. Ken Schwaber i Jeff Sutherland opisał wszystkie zasady wytwarzania projektów w The Scrum Guide.

32 Cykl Scrum

33 Członkowie zespołu Product owner Scrum master Development team

34 Product owner Właściciel produktu reprezentuję interesariuszy projektu i jest głosem klientów w dyskusjach nad wytwarzaniem produktu. Przedstawia produkt przed interesariuszami Określa wydania produktu Organizuje spotkanie rejestr spintu Uczestniczy w ustalaniu zakresu, kosztorysu, harmonogramu Pilnuje rejestru produktów

35 Scrum master Scrum jest prowadzony przez Scrum Mastera, który pilnuje aby zespół Scrumowy dostarczał dokładnie taki produkt jakiego oczekuje klient, Pilnuje procedur scrumowych Uczy zespół samoorganizującej pracy Pomaga zespołowi w rozwiązywaniu problemów realizacyjnych Organizuje spotkania podsumowujące postępy w pracach

36 Development team Development team jest odpowiedzialny za dostarczenie kolejnych elementów produktu na koniec każdego sprintu, Zespół jest budowany z osób posiadających różnych umiejętności i cechy osobowościowe, Development team jest zespołem samoorganizującym swoje prace. Zespół składa się z ok 9 osób.

37 Scrum Events Sprint Daily scrum Sprint planning Sprint review Sprint retrospective Backlog refinement (Backlog grooming) Impediments Backlog

38 Sprint Sprint jest podstawowym zdarzeniem Scrum w którym jest realizowany projekt, Długość trwania sprintu waha się od 1-4 tygodni, Sprint rozpoczyna się od planowania sprintu a kończy się na podsumowaniu sprintu W trakcie realizacji sprintu odbywają się spotkania nieformalne Daily Scrum

39 Daily Scrum Spotkania odbywają się w teorii na stojąco i nie powinno trwać dłużej niż 15 minut, Spotkania mają charakter nieformalny ale mają bardzo duże znaczenie dla organizacji pracy zespołu. W trakcie spotkań następuje podsumowanie tego co zostało wykonane dnia poprzedniego, następuje reakcja na odstępstwa oraz jest planowana praca na najbliższy dzień. What did I do yesterday that helped the development team meet the sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal?

40 Sprint planning Spotkanie mające na celu wybór funkcjonalności jakie będą rozwijane w kolejnym sprincie, Spotkanie składa się z dwóch (zazwyczaj 4h) części: Pierwsza połowa- spotkanie całego Scrum Team na którym jest ustalany zakres elementów z rejestru produktów jaki wejdzie do realizacji w najbliższej perspektywie sprintowej Druga połowa spotkanie Developer team, który przygotowuje w oparciu o wybrane do realizowania funkcjonalności listę zadań do wykonania sprint backlog

41 Sprint review Podsumowanie prac wykonanych w ramach sprintu Rozliczenie z prac wykonany oraz niewykonanych Prezentacja produktu opracowanego w ostatnim Sprint

42 Sprint retorspective Poprawa sposoby działania dotychczas opracowanego produktu W jakich aspektach tworzony produkt jest zgodny z oczekiwaniami m, co nie działa tak jak powinno Zebranie i przekazanie uwag na spotkaniu planującym Scrum

43 Backlog Grooming Proces polegający na uzupełnianiu i poprawianiu rejestru produktów, W trakcie Backlog Grooming jest kontrolowana priorytetyzacja poszczególnych funkcjonalności

44 Scrum artifacts Product backlog Sprint backlog Product increment

45 Product backlog Backlog Produktu to uporządkowana lista wszystkiego, co może być potrzebne w produkcie oraz jedyne źródło wymaganych zmian, które mają być w produkcie wprowadzone, Backlog Produktu nigdy nie jest kompletny. Elementy Backlogu Produktu posiadają następujące atrybuty: opis, kolejność, oszacowanie i wartość.

46 Backlog Sprintu Zbiór elementów Backlogu Produktu wybranych do Sprintu rozszerzony o plan dostarczenia Przyrostu produktu i realizacji Celu Sprintu. Służy do prognozy, które funkcjonalności znajdą się w kolejnym przyroście i jaką pracę należy wykonać, aby te funkcjonalności dostarczyć w postaci Ukończonego Przyrostu. Backlog Sprintu to plan w stosunku do którego jest analizowany postęp prac na codziennych spotkaniach Scrum Daily Scrum.

47 Product increment Przyrost jest sumą wszystkich elementów Backlogu Produktu zakończonych podczas Sprintu i wszystkich Sprintów poprzednich, Na koniec Sprintu nowy Przyrost musi być Ukończony, co oznacza, że musi on być gotowy do użycia i zgodny z Definicją Ukończenia danego Zespołu Scrumowego Przyrost musi być gotowy do użycia niezależnie od tego, czy Właściciel Produktu decyduje się na jego wydanie.

48