2017-01-26 Metodyki zarządzania i wytwarzaniawojciechowski.pl/4students/Projektowanie...

2017-01-26

1

METODYKI ZARZĄDZANIA PROCESEM I REALIZACJI PROJEKTÓW INFORMATYCZNYCH: RUP, PRINCE2, XP, XPRINCE, SCRUM

Adam Wojciechowski

Metodyki zarządzania i wytwarzania

Tradycyjne RUP (Rational Unified Process) – spiralny, rozbudowany PRINCE2 (Projects In Controlled Environments) –

kaskadowy, rozbudowany

Zwinne (agile) Scrum eXtreme Programming, XP XPrince (połączenie Prince2 , XP oraz RUP)

Model kaskadowy

Planowanie

Analiza

Projekt

Implementacja

Testowanie

Wdrożenie

Pielęgnacja

Model kaskadowy

1. Planowanie systemu (w tym specyfikacja wymagań)

2. Analiza systemu (w tym analiza wymagań i studium wykonalności)

3. Projekt systemu (model poszczególnych struktur itp.)4. Implementacja (napisanie/wygenerowanie kodu)

5. Testowanie (jednostkowe i funkcjonalne)6. Wdrożenie i pielęgnacja systemu Wadą jest nieelastyczny podział na kolejne fazy

Nie można przejść do następnej fazy przed zakończeniem poprzedniej

Iteracje są bardzo kosztowne - powtarzamy wiele czynności

Model przyrostowy

Planowanie Wdrożenie

Wymagania Implementacja

Ewaluacja Testowanie

Wydanie systemu

Model spiralny

Zadania w każdym cyklu Określenie celu

Rozpoznanie i mitygacja zagrożeń

Budowa i zatwierdzenie

Ocena i planowanie

Źródło rys.: wikipedia

2017-01-26

2

Model spiralny i przyrostowy

Częste kontakty z klientem (w porównaniu do modelu kaskadowego) Faza oceny w każdym cyklu (pozwala uniknąć błędów lub wcześniej

je wykryć) Wykorzystanie przez klienta fragmentów systemu (prototypy) Brak konieczności zdefiniowania z góry całości wymagań - cały czas

istnieje możliwość rozwijania projektu Częste kontrole jakości w kolejnych cyklach - nastawienie na

wykrywanie błędów i działania kontrolne, a nie na zapobieganie Orientacja na zarządzanie, czas i budżet.

Trudności z określeniem podzbioru funkcji niezależnych (moduły) Konieczność implementacji szkieletu – dodatkowy nakład pracy Wysoki koszt usuwania błędów wykrytych w finalnych etapach

projektu

Często popełniane błędy i trudności w zarządzaniu i realizacji projektów inf. Zarządzanie wymaganiami ad hoc (najczęściej brak

zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura oprogramowania nieodporna na obciążenia

(ang. Brittle architecture) Zbytnia, niepotrzebna złożoność oprogramowania Niewykryte niespójności w wymaganiach, projekcie oraz

implementacji Brak lub niewystarczające testowanie Subiektywna ocena postępu projektu Brak zarządzania ryzykiem Brak automatyzacji prowadzenia projektu

Co to jest RUP?Rational Unified Process

RUP is a knowledge base, containing software engineering practices thatrepresent many of the bestpractices observed insuccessful software development

http://www-306.ibm.com/services/learning/ites.wss?pageType= course_description&courseCode=RP401&country=us&language=en

Odpowiedź na błędy w zarządzaniu i realizacji projektów informat.

RUP

Rational Unified Process (RUP) – proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę RationalSoftware Corporation (przedsiębiorstwo zostało przejęte przez IBM)

Proces RUP nie jest pojedynczym, ściśle określonym procesem, ale raczej szablonem procesu. Został on zaprojektowany w celu przystosowania do charakteru konkretnej organizacji (przedsiębiorstwa), konkretnego zespołu projektowego lub nawet charakteru konkretnego projektu. Z szablonu RUP można wybrać elementy w zależności od konkretnych potrzeb.

Rational Unified Process (RUP) to także nazwa oprogramowania, opracowanego przez Rational Software (obecnie dostępnego w IBM). Produkt ten zawiera hipertekstową bazę wiedzy z przykładowymi artefaktami oraz szczegółowymi opisami wielu typów czynności. Process RUP definiowany jest także w produkcie Rational Method Composer (RMC), który pozwala na tworzenie spersonalizowanych wersji RUP.

Metodyka RUP

RUP bazuje na zbiorze zasad inżynierii programowania oraz najlepszych praktykach, na przykład: iteracyjnym wytwarzaniu oprogramowania (Iterative

Development) zarządzaniu wymaganiami (Requirement Management) używaniu architektury bazującej na komponentach

(Component-based architecture) graficznym projektowaniu oprogramowania kontroli jakości oprogramowania (Quality Assurance) procesu kontroli zmian w oprogramowaniu (Change

Management)

Fazy w RUP

Cykl życia w RUP bazuje na modelu spiralnym i układa zadania w fazy i iteracje.

Projekt został podzielony na cztery fazy:

faza rozpoczęcia (Inception phase) faza opracowywania (Elaboration phase) faza konstrukcji (Construction phase) faza przekazania systemu (Transition phase)

2017-01-26

3

Fazy w RUP Dyscypliny RUP (Disciplines and workflows)

RUP bazuje na zbiorze klocków (building blocks, content elements). Opisują one, co ma zostać stworzone, jakie umiejętności są do tego wymagane oraz, krok po kroku, jak powinien wyglądać proces wytwarzania. Rola (Roles) – Kto? – Rola definiuje zbiór wymaganych umiejętności, kompetencji i

odpowiedzialności. Produkt (Work Products) – Co? – Produkt reprezentuje wynik zadania oraz

wszystkie dokumenty i modele utworzone w czasie procesu. Zadanie (Tasks) – Jak? – Zadanie opisuje jednostkę pracy przypisaną do roli.

W ramach każdej iteracji zadania podzielone są na dziewięć dyscyplin:

Dyscypliny inżynierskie:Modelowanie biznesowe (Business modeling)Wymagania (Requirements)Analiza i projekt (Analysis and design)Implementacja (Implementation)Testowanie (Test)Wdrożenie (Deployment)

Dyscypliny pomocnicze :Zarządzanie zmianami oraz konfiguracją (Configuration and changemanagement)Zarządzanie projektem (Project management)Środowisko (Environment)

PRINCE2: wprowadzenie

PRINCE = PRojects IN Controlled EnvironmentsCCTA = Central Computer and Telecommunications Agency, UK

1989: CCTA wprowadza metodę PRINCE

1996: CCTA ogłasza metodę PRINCE2

Metodyka zarządzania przedsięwzięciamiGłówny aktor: kierownik przedsięwzięcia

Projekt – definicja PRINCE2

Środowisko zarządcze stworzone w celu dostarczenia jednego lub większej liczby produktów biznesowych zgodnie z określonym Uzasadnieniem Biznesowym.

lub

Organizacja powołana na określony czas, w celu wytworzenia unikatowych i wcześniej zdefiniowanych wyników lub rezultatów w ustalonym czasie, przy wykorzystaniu uprzednio określonych zasobów.

Cykl życia projektu, okres życia produktu a PRINCE2

PomysłBadaniaDecyzja

SpecyfikacjaProjekt Techniczny

WytworzenieTestowaniePrzekazanie

Ocena efektówUżytkowanie

Likwidacja

Okres życia produktu

Okres od momentu pierwszego pomysłu na produkt aż do jego wycofania z eksploatacji

Prawdopodobnie w okresie życia produktu dotyczyć go będzie wiele projektów – studium wykonalności, wytworzenie, rozwój i udoskonalenia lub korekty.

Okres życia projektu

Okres od rozpoczęcia projektu aż do przekazania ukończonego produktu tym, którzy będą goeksploatować i utrzymywać

PRINCE2 obejmuje cykl życia projektu i część przygotowań przed projektem oraz decyzję zezwalającą na rozpoczęcie zainicjowania projektu

Studium wykonalności – cykl życia projektu

Jeśli wymagane jest opracowanie studium wykonalności w celu zbadania istniejącej sytuacji i określenia wariantów dalszego postępowania, wtedy optymalnym podejściem jest potraktowanie studium wykonalności jako osobnego i niezależnego projektu.

Zdefiniowanie problemu Badania

Przygotowanie wariantów

Przedstawienie rekomendacji

Projekt taki to:• jeden Plan Projektu• jedno Uzasadnienie Biznesowe • jeden zbiór zagrożeń (ryzyko)• jeden produkt końcowy - rekomendacje

2017-01-26

4

Kierownik Zesp.

Struktura zarządzania wg PRINCE 2

Komitet Sterujący

Reprezentant użytkowników

Przewodniczący Reprezentant dostawcy

Kierownik Przedsięwzięcia

Nadzór Przedsięwzięcia Raport

Plan

Kierownik Zesp.Kierownik Zesp.

Kierownik Zesp.

Struktura zarządzania wg PRINCE 2

Komitet Sterujący

Reprezentant użytkowników

Przewodniczący Reprezentant dostawcy

Kierownik Przedsięwzięcia

Nadzór Przedsięwzięcia

Zlecenie

Raport

Kierownik Zesp.Kierownik Zesp.

Raport

Plan

Wsparcie Przedsięwzięcia

Cykl życia wg PRINCE 2 – Pierwsza przymiarka16.10 27.11 23.01 8.04 27.05 17.06 1.07

Przyg. zał. Proj

Inicj. projektu

Etap 1 Etap 2 Etap 3 Etap 4 Zamknięcie


Przyg. zał. Proj

Inicj. projektu


Zarządzanie zakresem etapu SB

Przyg. założeń projektu SU

Inicjowanie projektu IP

Zamknięcie projektu CP

Zarządzanie etapem


Przyg. zał. Proj

Inicj. projektu






Zarządzanie etapem

PlanowaniePL

Cykl życia wg PRINCE 2





Zarządzanie etapem

PlanowaniePL

Strategiczne zarządzanie projektem DP

2017-01-26

5

Cykl życia wg PRINCE 2





Zarządzanie etapem

PlanowaniePL

Strategiczne zarządzanie projektem DP

Zarządzanie wytwarzaniem

produktów

Sterowanie etapemCS

Procesy PRINCE2

Przygotowanie Projektu Inicjowanie Projektu Zarządzanie Strategiczne Projektem Sterowanie Etapem Zarządzanie Wytwarzaniem Produktów Zarządzanie Zakresem Etapu Zamykanie Projektu Planowanie

Agile Manifesto

Manifest Agile (Agile Manifesto, Manifesto for Agile Software Development) to deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania. Została opracowana na spotkaniu jakie miało miejsce w dniach 11-13 lutego 2001 roku w ośrodku wypoczynkowym Snowbird w USA.

Treść Manifestu AgileWytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywa się lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkłada się: Ludzie i interakcje ponad procesy i narzędzia Działające oprogramowanie ponad obszerną dokumentację Współpracę z klientem ponad formalne ustalenia Reagowanie na zmiany ponad podążanie za planem

Według Manifestu Agile docenia się to, co wymieniono po prawej stronie, jednak bardziej ceni się to, co po lewej.

eXtreme Programming

XP to paradygmat i metodyka programowania mające na celu wydajne tworzenie małych i średnich "projektów wysokiego ryzyka", czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić. Przyświeca temu koncepcja prowadzenia projektu informatycznego, wywodząca się z obserwacji innych projektów, które odniosły sukces.

Praktyki XP

Kod

Testy

Metafora

Małe przyrosty

Gra Planistyczna Klient w

zespole

RefaktoryzacjaProgramowanie

parami

Test przed kodem

Prosty projekt

Współwłasnośćkodu

Częsta integracja

Standard kodowania Brak

nadgodzin

XPrince

XPrince (Extreme Programming in Controlled Environments) –zwinna metodyka wytwarzania oprogramowania, której celem jest wyważenie między zwinnością i dyscypliną. Bazuje ona na: XP, PRINCE2 oraz RUP.

Słabe strony XP to wymóg, aby klient pracował razem z zespołem, brak dokumentacji papierowej oraz czasami zbyt krótka perspektywa planowania.

Celem, który przyświecał stworzeniu metodyki XPrince, było rozwiązanie problemów związanych ze słabościami XP oraz zachowanie adaptacyjności. W związku z tym metodyka ta integruje metodykę zarządzania projektem (PRINCE2) z metodyką wytwarzania oprogramowania (XP).

2017-01-26

6

XPrince

Źródło: http://www.mif.pg.gda.pl/homepages/sylas/students/sem_podypl/io-w05.pdf, slajd 40

a) PRINCE2b) RUPc) XPd) XPrince

SCRUM

Rozwój produktu podzielony na fazy (tzw. Sprinty) trwające kilka tygodni Funkcjonalności zbierane od klienta (user stories), segregowane na sprinty

(sprint planning). 15-minutowe spotkania każdego dnia (daily scrum) opisujące zadania na

dany dzień i podsumowujące dzień poprzedni (sprint review). Każdy odpowiada na 3 pytania.

Działająca wersja wytwarzana po każdym sprincie (musi być widoczna zmiana z poprzedniej wersji). Zapis zmian w rejestrze (sprint backlog)

Właściciel produktu – ustala priorytety, ustala cel pierwszego przebiegu. (na podstawie tego tworzony jest backlog)

Zespół – tworzy produkt. Samodzielnie przypisuje zadania do wykonania Scrum master – odpowiada za usuwanie problemów oraz poprawną

implementacje procesu.

Źródło: https://www.mountaingoatsoftware.com/agile/scrum/a-reusable-scrum-presentation

Charakterystyka SCRUM

Samoorganizujące się zespoły Postęp prac nad produktem następuje w

miesięcznych „sprintach” Wymagania są gromadzone w postaci listy

rejestru produktu - “product backlog” Brak narzuconych praktyk inżynierskich Ustalone reguły w celu stworzenia zwinnego

środowiska projektowego Jeden z wielu „zwinnych procesów”


Rozwój sekwencyjny a nakładający się

Źródło: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

Zamiast robić każdą rzecz po kolei

…w scrumie robimy wszystkiego trochę

Wymagania Projekt Kodowanie Test


Ramy Scrum

•Właściciel produktu•Mistrz (ScrumMaster)•Zespół

Role

•Planowanie sprintu•Przegląd sprintu•Retrospektywa•Codzienny scrum

Rytuały

•Rejestr produktowy•Rejestr sprintu•Wykres wypalania

Artefakty


Ramy Scrum


Role


Rytuały


Artefakty


2017-01-26

7

Właściciel produktu (Product owner)

Definiuje funkcjonalności produktu Decyduje o dacie wydania i zawartości Jest odpowiedzialny za dochodowość/ zwrot z

inwestycji (ROI) dla produktu Priorytetyzuje funkcjonalności według ich wartości

rynkowej. Dostosowuje priorytety w iteracjach Akceptuje wykonanie pracy


Mistrz - The ScrumMaster

Reprezentuje management w projekcie

Odpowiada za wdrażanie praktyk i wartości Scrum

Usuwa przeszkody

Czuwa nad produktywnością zespołu

Ułatwia współpracę pomiędzy funkcjami

Chroni zespół przed zewnętrznymi ingerencjami


Zespół - The team

Zwykle 5-9 osób

WielofunkcyjnyProgramisci, testerzy, projektanci user experience itd.

Członkowie pracują na cały etatMogą być wyjątki (np. administrator baz danych)


Zespół - The team

Samoorganizujacy się Idealnie bez tytułów lecz wyjątkowo są one

dopuszczalne

Skład zespołu może się zmieniać tylko pomiędzy sprintami


Ramy Scrum


Role


Rytuały


Artefakty


Spotkanie planistyczne

Ustalenie priorytetów

• Analiza i szacowanie rejestru produktu

• Wybranie celu sprintu

Planowanie sprintu

• Plan osiągnięcia celu sprintu• Przygotowanie rejestru sprintu

(zadań) z rejestru produktu (opowieści użytkownika/ funkcjonalności)

• Estymacja rejestru produktu (h)

Cel sprintuCel sprintu

Rejestr sprintuRejestr sprintu

Warunki biznesoweWarunki biznesowe

Wydajność zespołuWydajność zespołu

Rejestr produktowyRejestr produktowy

Techno-logiaTechno-logia

Właściwy produktWłaściwy produkt


2017-01-26

8

Planowanie sprintu

Zespół wybiera pozycje z rejestru produktu, do których wykonania może się zobowiązać

Zostaje utworzony rejestr sprintu Zadania zostają zidentyfikowane i każde z nich zostaje

estymowane (1-16 godzin)

Planowanie wykonuje cały zespół a nie ScrumMaster

Uwzględniony jest projekt całościowy

Jako osoba wybierająca się na wakacje chciałbym zobaczyć zdjęcia hoteli.

Jako osoba wybierająca się na wakacje chciałbym zobaczyć zdjęcia hoteli.

Warstwa funkcjonalna (8h)Interfejs użytkownika (4h)Testy jednostkowe (4h)Wykonanie klasy foo (6h)Testy wydajnościowe (4h)


Codzienny scrum

Parametry Codziennie 15-minut Na stojaco

Nie służy do rozwiazywania problemów Zapraszamy cały świat Mówić mogą tylko członkowie zespołu, ScrumMaster i

właściciel produktu

Pomaga w unikaniu dodatkowych spotkań


Każdy odpowiada na 3 pytania

Odpowiedzi nie są raportem dla ScrumMastera Są deklaracją przed innymi członkami zespołu

Co robiłeś wczoraj?Co robiłeś wczoraj?11

Co będziesz robić dzisiaj?Co będziesz robić dzisiaj?22

Czy coś utrudnia pracę?Czy coś utrudnia pracę?33


Przegląd sprintu

Zespół prezentuje co osiągnął w sprincie Zazwyczaj ma postać demo nowych funkcji lub

architektury Nieformalny

Zasada: 2 godzinyprzygotowań

Brak slajdów Uczestniczy cały zespół Zapraszamy cały świat


Retrospektywa

Okresowo, weryfikacja, co działa, a co nie Zwykle 15-30 minut Po każdym sprincie Uczestniczy cały zespół

ScrumMaster Właściciel produktu Zespół Mogą być klienci oraz inni uczestnicy


Start / Stop / Kontynuacja

Cały zespół przedstawia i omawia co chciałby:

Zacząć robićZacząć robić

Przestać robićPrzestać robić

KontynuowaćKontynuowaćTo tylko jeden ze sposobów przeprowadzenia retrospektywy sprintu


2017-01-26

9

Ramy Scrum


Role


Rytuały


Artefakty


Rejestr produktu

Wymagania Lista wszystkich pożądanych

prac w projekcie Idealnie-zapisane w taki

sposób, aby każda pozycja przedstawiała wartość dla użytkownika lub klienta

Priorytety ustala właściciel produktu

Korekta priorytetów na początku każdego sprintuTo jest rejestr

produktuTo jest rejestr produktu


Przykładowy rejestr produktu

Pozycja Estymata

Gość może wykonać rezerwację. 3

Jako gość chcę mieć możliwość anulowania rezerwacji. 5

Jako gość chcę zmienić datę rezerwacji. 3

Jako pracownik hotelu chcę mieć możliwość uruchomienia raportu RevPAR (revenue-per-available-room)

8

Poprawiona obsługa wyjątków 8

... 30

... 50Źródło: https://www.mountaingoatsoftware.com/agile/scrum/a-reusable-scrum-presentation

Cel sprintu

Krótkie zdanie informujące, na jakiej pracy skupimy się podczas kolejnego sprintu

Aplikacja bazodanowa

Usługi finansowe

Nauki przyrodnicze

Wykonanie podstawowych funkcjonalności do badań DNA

Wsparcie dla większej liczby finansowych wskaźników technicznych niż ma firma ABC

Możliwość uruchamiania aplikacji na bazie SQL Server oprócz Oracle


Zarządzanie rejestrem sprintu

Członkowie zespołu sami wybierają prace, które chcą wykonać Praca nie jest przydzielana odgórnie

Praca pozostała do wykonywania jest aktualizowana codziennie


Zarządzanie rejestrem sprintu

Każdy członek zespołu może dodawać, usuwać lub zmieniać rejestr sprintu

Pojawiają się prace do wykonania

Jeżeli praca jest niejasna, zdefiniuj pozycję rejestru z większym planowanym czasem, a następnie podziel go na mniejsze fragmenty

Aktualizuj rejestr pozostałej pracy w miarę jak coraz więcej jest wiadome


2017-01-26

10

Rejestr sprintu

ZadanieInterfejs użytkownika

Środkowa warstwa

Test środkowej warstwa

Napisanie pomocy online

Napisanie klasy foo

PonPon.8

16

8

12

8

Wt.4

12

16

8

ŚrŚr. Czw.

4

11

8

4

Pt.Pt.

8

8

Dodaj log błędów

8

10

16

8

8


Wykres wypalania sprintu

God

ziny


ZadanieInterfejs użytkownika

Środkowa warstwa

Test środkowej warstwa

Pon. Wt. Śr. Czw. Pt.

God

ziny

40

30

20

10

0 Mon Tue Wed Thu Fri

8

168

12

4

1216

711

8

1016 8

50

Napisanie pomocy online


Skalowalność SCRUM

Typowy zespół składa się z 7 ± 2 osób Skalowalność poprzez zespoły zespołów

Czynniki podczas skalowania Typ aplikacji Rozmiar zespołu Rozproszenie zespołuCzas trwania projektu

Scrum był stosowany w projektach, w których uczestniczyło ponad 500 osób


DYSKUSJA

2017-01-26 Metodyki zarządzania i wytwarzaniawojciechowski.pl/4students/Projektowanie...

Documents

Transcript of 2017-01-26 Metodyki zarządzania i wytwarzaniawojciechowski.pl/4students/Projektowanie...