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.