Projektowanie oprogramowania systemów METODYKI PROJEKTOWE

Projektowanie oprogramowania systemów METODYKI PROJEKTOWE

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ć

diagram klas UML diagramów UML

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

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)

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)

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

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

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

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

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

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

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) - http://astah.net/download#community Microsoft Visio do pobrania z DreamSpark Eclipse + EMF/GEF/UML2 (free) www.eclipse.org NetBeans Microsoft Visual Studio DreamSpark mnóstwo innych, ale tylko nieliczne darmowe implementują cały UML (większość diagramy klas + kilka innych)

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

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

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

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

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.

Podział

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

https://davenicolette.files.wordpress.com/2012/02/rup.png

Cykl RUP http://www.psa-software.com/rup.php

PRINCE2 (PRojects IN Controlled Environments)

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

PRINCE2 - struktura organizacji

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)

PMBoK (Project Management Body of Knowledge)

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.

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.

https://www.advisicon.com/wp-content/uploads/pmbok_5_process_group_map.jpg

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. http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

Cykl Scrum

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

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

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

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.

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

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

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?

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

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

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

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

Scrum artifacts Product backlog Sprint backlog Product increment

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ść.

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.

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.