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.