Metodyka XPrince: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
mNie podano opisu zmian
Nie podano opisu zmian
Linia 1: Linia 1:
'''XPrince (Extreme Programming in Controlled Environments)''' jest jedną ze [[Adaptacyjne zarządzanie projektami|zwinnych metodyk]] wytwarzania oprogramowania, której celem jest wyważenie między zwinnością i dyscypliną<ref>Mastalerz M. W., (2015), ''Zeszyty Naukowe Uniwersytetu Szczecińskiego. Studia Informatica'', str.81 </ref>. Bazuje na trzech innych metodykach takich jak [[Metodyka Extreme Programming|Extreme Programming]] (XP), [[Metodyka PRINCE II|PRINCE2]] oraz Rational Unified Process (RUP). Jest ona metodyką zwinną, zawierającą jednak elementy kontroli przedsięwzięcia (w aspektach jakości, ryzyka, pracy) oraz niezbędny poziom wymaganej dokumentacji (z wykorzystaniem niektórych diagramów UML)<ref>Miłosz M., Borys M., Plechawska-Wójcik M., (2011), ''Współczesne technologie informatyczne. Metodyki zwinne wytwarzania oprogramowania'', Politechnika Lubelska, str. 19</ref>. Podobnie jak w metodyce [[Metodyka PRINCE II|PRINCE2]] w XPrince do kontroli projektu dochodzi na różnych poziomach.
'''XPrince (Extreme Programming in Controlled Environments)''' jest jedną ze [[Adaptacyjne zarządzanie projektami|zwinnych metodyk]] wytwarzania oprogramowania, której celem jest wyważenie między zwinnością i dyscypliną<ref>Mastalerz M. W., (2015), ''Zeszyty Naukowe Uniwersytetu Szczecińskiego. Studia Informatica'', str.81 </ref>. Bazuje na trzech innych metodykach takich jak [[Metodyka Extreme Programming|Extreme Programming]] (XP), [[Metodyka PRINCE II|PRINCE2]] oraz Rational Unified Process (RUP). Jest ona metodyką zwinną, zawierającą jednak elementy kontroli przedsięwzięcia (w aspektach jakości, ryzyka, pracy) oraz niezbędny poziom wymaganej dokumentacji (z wykorzystaniem niektórych diagramów UML)<ref>Miłosz M., Borys M., Plechawska-Wójcik M., (2011), ''Współczesne technologie informatyczne. Metodyki zwinne wytwarzania oprogramowania'', Politechnika Lubelska, str. 19</ref>. Podobnie jak w metodyce [[Metodyka PRINCE II|PRINCE2]] w XPrince do kontroli projektu dochodzi na różnych poziomach.
 
==Historia powstania==
==Historia powstania==
Twórcą metodyki XPrince jest prof. Jerzy Nawrocki z Instytutu Informatyki Politechniki Poznańskiej. Jego celem było stworzenie metodyki, która pozwoli zachować równowagę pomiędzy adaptacyjnością, a dyscypliną. Żeby go zrealizować prof. Nawrocki zintegrował metodyki wytwarzania oprogramowania [[Metodyka Extreme Programming|Extreme Programming]] (XP) i RUP z metodyką zarządzania projektem [[Metodyka PRINCE II|PRINCE2]]. Wybrał najlepsze cechy z powyższych metodyk oraz starał się wyeliminować ich wady. Metodyka powstała w roku 2003<ref>Trąbka J., (2011), ''Zarządzanie projektem wdrożeniowym systemu klasy ERP - autorska metodyka'', Metody Informatyki Stosowanej, Szczecin, str.93</ref>.
Twórcą metodyki XPrince jest prof. Jerzy Nawrocki z Instytutu Informatyki Politechniki Poznańskiej. Jego celem było stworzenie metodyki, która pozwoli zachować równowagę pomiędzy adaptacyjnością, a dyscypliną. Żeby go zrealizować prof. Nawrocki zintegrował metodyki wytwarzania oprogramowania [[Metodyka Extreme Programming|Extreme Programming]] (XP) i RUP z metodyką zarządzania projektem [[Metodyka PRINCE II|PRINCE2]]. Wybrał najlepsze cechy z powyższych metodyk oraz starał się wyeliminować ich wady. [[Metodyka]] powstała w roku 2003<ref>Trąbka J., (2011), ''[[Zarządzanie]] projektem wdrożeniowym systemu klasy ERP - autorska metodyka'', Metody Informatyki Stosowanej, Szczecin, str.93</ref>.
<google>t</google>
<google>t</google>
W roku 2004 zostało założone Konsorcjum XPrince, którego celem jest rozwój i promocja tej metodyki. W skład konsorcjum weszła Politechnika Poznańska oraz grupa firm produkujących oprogramowanie. Także w 2004 roku twórcy metodyki XPrince przygotowali narzędzie UC Workbench, które wspiera proces inżynierii wymagań. Jest ono w pełni zgodne ze sposobem specyfikacji przypadków użycia określonym w metodyce. W 2007 roku została wydana druga wersja tego narzędzia. Program UC Workbench zawiera następujące funkcje<ref>Olek Ł., Nawrocki J., Jasiński M., Paliświat B., Walter B., Pietrzak B., Godek P., ''Równowaga między zwinnością a dyscypliną z wykorzystaniem XPrince'', Politechnika Poznańska, str. 8</ref>:
W roku 2004 zostało założone [[Konsorcjum]] XPrince, którego celem jest [[rozwój]] i [[promocja]] tej metodyki. W skład konsorcjum weszła Politechnika Poznańska oraz [[grupa]] firm produkujących oprogramowanie. Także w 2004 roku twórcy metodyki XPrince przygotowali narzędzie UC Workbench, które wspiera [[proces]] inżynierii wymagań. Jest ono w pełni zgodne ze sposobem specyfikacji przypadków użycia określonym w metodyce. W 2007 roku została wydana druga wersja tego narzędzia. [[Program]] UC Workbench zawiera następujące funkcje<ref>Olek Ł., Nawrocki J., Jasiński M., Paliświat B., Walter B., Pietrzak B., Godek P., ''[[Równowaga]] między zwinnością a dyscypliną z wykorzystaniem XPrince'', Politechnika Poznańska, str. 8</ref>:
* ''Edytor przypadków użycia'' dający możliwość zautomatyzowania renumeracji kroków w głównym scenariuszu
* ''Edytor przypadków użycia'' dający możliwość zautomatyzowania renumeracji kroków w głównym scenariuszu
* ''Automatyczne przeglądy'' posiadające opcję wykrywania potencjalnych błędów
* ''Automatyczne przeglądy'' posiadające opcję wykrywania potencjalnych błędów
* ''Generowanie makiet funkcjonalnych'' na podstawie zebranych przypadków użycia. Makieta generowana jest automatycznie i posiada dwa okna. Pierwsze z nich to okno scenariusza, które przedstawia aktualnie animowany przypadek użycia, drugie to okno ekranów, na którym widać projekt wyglądu formularzy aplikacji. W oknie ekranów mogą także znajdować się diagramy BPMN w przypadku procesów biznesowych.
* ''Generowanie makiet funkcjonalnych'' na podstawie zebranych przypadków użycia. Makieta generowana jest automatycznie i posiada dwa okna. Pierwsze z nich to okno scenariusza, które przedstawia aktualnie animowany przypadek użycia, drugie to okno ekranów, na którym widać [[projekt]] wyglądu formularzy aplikacji. W oknie ekranów mogą także znajdować się diagramy BPMN w przypadku procesów biznesowych.
* ''Komponowanie dokumentu specyfikacji wymagań'', które opiera się na standardzie IEEE 830-1998. Specyfikacja wymagań generowana jest w programie UC Workbench z przypadków użycia.
* ''Komponowanie dokumentu specyfikacji wymagań'', które opiera się na standardzie IEEE 830-1998. [[Specyfikacja]] wymagań generowana jest w programie UC Workbench z przypadków użycia.
* ''Kalkulator pracochłonności bazujący na metodzie UC Points'', który wspomaga Grę Planistyczną z metodyki [[Metodyka Extreme Programming|XP]]. W metodyce Prince planowanie prowadzone jest na trzech poziomach. Najniższy z nich to metoda UC Points podająca domyślne szacunki, które mogą później być dostosowane przez ekspertów. Drugi poziom to metoda delficka, która używana jest aby oszacować pracochłonność. Najwyższy poziom to Gra Planistyczna, która ma na celu uzgodnienie pomiędzy programistami, a klientem i Analitykiem zakresu kolejnego wydania.
* ''Kalkulator pracochłonności bazujący na metodzie UC Points'', który wspomaga Grę Planistyczną z metodyki [[Metodyka Extreme Programming|XP]]. W metodyce Prince [[planowanie]] prowadzone jest na trzech poziomach. Najniższy z nich to [[metoda]] UC Points podająca domyślne szacunki, które mogą później być dostosowane przez ekspertów. Drugi poziom to [[metoda delficka]], która używana jest aby oszacować [[pracochłonność]]. Najwyższy poziom to Gra Planistyczna, która ma na celu uzgodnienie pomiędzy programistami, a klientem i Analitykiem zakresu kolejnego wydania.


==Zespół projektowy==
==Zespół projektowy==
Struktura zespołu projektowego jest płaska, podobnie jak w innych metodykach zwinnych. W metodyce XPrince wykorzystane są skondensowane struktury zarządcze projektu, a w części wykonawczej występują kilkuosobowe zespoły, które pojawiają się w podejściu zwinnym.
[[Struktura zespołu]] projektowego jest płaska, podobnie jak w innych metodykach zwinnych. W metodyce XPrince wykorzystane są skondensowane struktury zarządcze projektu, a w części wykonawczej występują kilkuosobowe zespoły, które pojawiają się w podejściu zwinnym.


'''Zespół zarządzający projektem'''
'''[[Zespół]] zarządzający projektem'''
* Dyrektor - reprezentuje interesy inwestora
* [[Dyrektor]] - reprezentuje interesy inwestora
* Główny użytkownik - kieruje końcowymi użytkownikami oraz jest odpowiedzialny za użyteczność programu
* Główny [[użytkownik]] - kieruje końcowymi użytkownikami oraz jest odpowiedzialny za [[użyteczność]] programu
* Główny dostawca - reprezentuje wykonawcę
* Główny [[dostawca]] - reprezentuje wykonawcę


'''Zespół wykonawczy'''
'''Zespół wykonawczy'''
* Menadżer projektu - odpowiada głównie za środowisko pracy, jego zadaniem jest rozwiązywanie problemów personalnych oraz oraz budowanie i motywacja zespołu. Jego rola wzorowana jest na metodyce [[Metodyka PRINCE II|PRINCE2]] połączonej z rolą trenera z metodyki [[Metodyka Extreme Programming|XP]] ukierunkowaną na zarządzanie zespołem.
* [[Menadżer]] projektu - odpowiada głównie za środowisko pracy, jego zadaniem jest rozwiązywanie problemów personalnych oraz oraz budowanie i [[motywacja]] zespołu. Jego rola wzorowana jest na metodyce [[Metodyka PRINCE II|PRINCE2]] połączonej z rolą trenera z metodyki [[Metodyka Extreme Programming|XP]] ukierunkowaną na [[zarządzanie zespołem]].
* Architekt - odpowiada ze podejmowanie decyzji projektowych, koordynuje oraz kieruje wykonywaniem czynności i artefaktów technicznych, jest również głównym projektantem. Jego rola została zaczerpnięta z metodyki RUP. Posiada także elementy trenera z metodyki [[Metodyka Extreme Programming|XP]] ukierunkowanego na aspekty techniczne.
* Architekt - odpowiada ze [[podejmowanie decyzji]] projektowych, koordynuje oraz kieruje wykonywaniem czynności i artefaktów technicznych, jest również głównym projektantem. Jego rola została zaczerpnięta z metodyki RUP. Posiada także elementy trenera z metodyki [[Metodyka Extreme Programming|XP]] ukierunkowanego na aspekty techniczne.
* Analityk - odpowiada ze biznesową analizę projektu i kontroluje ryzyko związane z funkcjonalnością oraz jakością produktów. Rola ta pochodzi z metodyki RUP oraz zawiera funkcję klienta z metodyki [[Metodyka Extreme Programming|XP]].
* Analityk - odpowiada ze biznesową analizę projektu i kontroluje [[ryzyko]] związane z funkcjonalnością oraz jakością produktów. Rola ta pochodzi z metodyki RUP oraz zawiera funkcję klienta z metodyki [[Metodyka Extreme Programming|XP]].
* Programiści
* Programiści


Linia 34: Linia 34:
| '''Wydanie 1'''
| '''Wydanie 1'''
|-
|-
| Przyrost 1.1 || Przyrost 1.2
| [[Przyrost]] 1.1 || Przyrost 1.2
|}
|}
  || ... ||
  || ... ||
Linia 47: Linia 47:
Rys. Schemat cyklu życia projektu w metodyce XPrince
Rys. Schemat cyklu życia projektu w metodyce XPrince


'''Cele w poszczególnych fazach życia projektu:'''
'''[[Cele]] w poszczególnych fazach życia projektu:'''
* '''Rozpoczęcie projektu''' - wybór zespołu zarządzającego projektem, przygotowanie wizji i koncepcji systemu, zaplanowanie fazy Inicjacji projektu.
* '''Rozpoczęcie projektu''' - wybór zespołu zarządzającego projektem, przygotowanie wizji i koncepcji systemu, zaplanowanie fazy Inicjacji projektu.
* '''Inicjacja projektu''' - faza przeprowadzana przez Menadżera Projektu, Analityka i Architekta, przygotowanie i dostarczenie planu projektu, propozycja wstępnej architektury, dopracowanie biznesowego uzasadnienia projektu, stworzenie środowiska organizacyjnego, wyznaczenie kanałów komunikacyjnych, sporządzenie listy potrzebnych narzędzi, zaplanowanie fazy Elaboracji. Faza ta łączy elementy fazy Rozpoczęcia z metodyki RUP oraz z Inicjacji z metodyki [[Metodyka PRINCE II|PRINCE2]].  
* '''Inicjacja projektu''' - faza przeprowadzana przez Menadżera Projektu, Analityka i Architekta, przygotowanie i dostarczenie planu projektu, propozycja wstępnej architektury, dopracowanie biznesowego uzasadnienia projektu, stworzenie środowiska organizacyjnego, wyznaczenie kanałów komunikacyjnych, sporządzenie listy potrzebnych narzędzi, zaplanowanie fazy Elaboracji. Faza ta łączy elementy fazy Rozpoczęcia z metodyki RUP oraz z Inicjacji z metodyki [[Metodyka PRINCE II|PRINCE2]].  
* '''Elaboracja''' - faza dotycząca głównie architektury, Architekt przedstawia opracowania mechanizmów architektonicznych z uwzględnieniem dotyczących ich ryzyk i przygotowuje szkielet projektu, Analityk doprecyzowuje wymagania projektu, a Menadżer projektu dopracowuje plan projektu.
* '''Elaboracja''' - faza dotycząca głównie architektury, Architekt przedstawia opracowania mechanizmów architektonicznych z uwzględnieniem dotyczących ich ryzyk i przygotowuje szkielet projektu, Analityk doprecyzowuje wymagania projektu, a Menadżer projektu dopracowuje [[plan]] projektu.
* '''Wydanie''' - etap ten zawiera kilka przyrostów (iteracji), które kończą się fazą tranzycji. Architekt wspólnie z Programistami produkuje kod oraz implementuje przypadki testowe, Analityk przygotowuje testy akceptacyjne i sprawdza zgodność kodu z wymaganiami. Po tranzycji następuje wdrożenie produktu lub zmian i przekazanie kolejnej wersji użytkownikom końcowym. Faza ta jest podobna do fazy Wydania z metodyki [[Metodyka Extreme Programming|XP]].
* '''Wydanie''' - etap ten zawiera kilka przyrostów (iteracji), które kończą się fazą tranzycji. Architekt wspólnie z Programistami produkuje kod oraz implementuje przypadki testowe, Analityk przygotowuje testy akceptacyjne i sprawdza zgodność kodu z wymaganiami. Po tranzycji następuje [[wdrożenie]] produktu lub zmian i przekazanie kolejnej wersji użytkownikom końcowym. Faza ta jest podobna do fazy Wydania z metodyki [[Metodyka Extreme Programming|XP]].
* '''Zamknięcie projektu''' - następuje sprawdzenie kompletności projektu, przygotowanie dokumentacji technicznej oraz ocena projektu. Faza wzorowana na metodyce [[Metodyka PRINCE II|PRINCE2]]
* '''Zamknięcie projektu''' - następuje sprawdzenie kompletności projektu, przygotowanie dokumentacji technicznej oraz [[ocena]] projektu. Faza wzorowana na metodyce [[Metodyka PRINCE II|PRINCE2]]


==Przypisy==
==Przypisy==

Wersja z 07:57, 25 lut 2022

XPrince (Extreme Programming in Controlled Environments) jest jedną ze zwinnych metodyk wytwarzania oprogramowania, której celem jest wyważenie między zwinnością i dyscypliną[1]. Bazuje na trzech innych metodykach takich jak Extreme Programming (XP), PRINCE2 oraz Rational Unified Process (RUP). Jest ona metodyką zwinną, zawierającą jednak elementy kontroli przedsięwzięcia (w aspektach jakości, ryzyka, pracy) oraz niezbędny poziom wymaganej dokumentacji (z wykorzystaniem niektórych diagramów UML)[2]. Podobnie jak w metodyce PRINCE2 w XPrince do kontroli projektu dochodzi na różnych poziomach.

Historia powstania

Twórcą metodyki XPrince jest prof. Jerzy Nawrocki z Instytutu Informatyki Politechniki Poznańskiej. Jego celem było stworzenie metodyki, która pozwoli zachować równowagę pomiędzy adaptacyjnością, a dyscypliną. Żeby go zrealizować prof. Nawrocki zintegrował metodyki wytwarzania oprogramowania Extreme Programming (XP) i RUP z metodyką zarządzania projektem PRINCE2. Wybrał najlepsze cechy z powyższych metodyk oraz starał się wyeliminować ich wady. Metodyka powstała w roku 2003[3]. W roku 2004 zostało założone Konsorcjum XPrince, którego celem jest rozwój i promocja tej metodyki. W skład konsorcjum weszła Politechnika Poznańska oraz grupa firm produkujących oprogramowanie. Także w 2004 roku twórcy metodyki XPrince przygotowali narzędzie UC Workbench, które wspiera proces inżynierii wymagań. Jest ono w pełni zgodne ze sposobem specyfikacji przypadków użycia określonym w metodyce. W 2007 roku została wydana druga wersja tego narzędzia. Program UC Workbench zawiera następujące funkcje[4]:

  • Edytor przypadków użycia dający możliwość zautomatyzowania renumeracji kroków w głównym scenariuszu
  • Automatyczne przeglądy posiadające opcję wykrywania potencjalnych błędów
  • Generowanie makiet funkcjonalnych na podstawie zebranych przypadków użycia. Makieta generowana jest automatycznie i posiada dwa okna. Pierwsze z nich to okno scenariusza, które przedstawia aktualnie animowany przypadek użycia, drugie to okno ekranów, na którym widać projekt wyglądu formularzy aplikacji. W oknie ekranów mogą także znajdować się diagramy BPMN w przypadku procesów biznesowych.
  • Komponowanie dokumentu specyfikacji wymagań, które opiera się na standardzie IEEE 830-1998. Specyfikacja wymagań generowana jest w programie UC Workbench z przypadków użycia.
  • Kalkulator pracochłonności bazujący na metodzie UC Points, który wspomaga Grę Planistyczną z metodyki XP. W metodyce Prince planowanie prowadzone jest na trzech poziomach. Najniższy z nich to metoda UC Points podająca domyślne szacunki, które mogą później być dostosowane przez ekspertów. Drugi poziom to metoda delficka, która używana jest aby oszacować pracochłonność. Najwyższy poziom to Gra Planistyczna, która ma na celu uzgodnienie pomiędzy programistami, a klientem i Analitykiem zakresu kolejnego wydania.

Zespół projektowy

Struktura zespołu projektowego jest płaska, podobnie jak w innych metodykach zwinnych. W metodyce XPrince wykorzystane są skondensowane struktury zarządcze projektu, a w części wykonawczej występują kilkuosobowe zespoły, które pojawiają się w podejściu zwinnym.

Zespół zarządzający projektem

Zespół wykonawczy

  • Menadżer projektu - odpowiada głównie za środowisko pracy, jego zadaniem jest rozwiązywanie problemów personalnych oraz oraz budowanie i motywacja zespołu. Jego rola wzorowana jest na metodyce PRINCE2 połączonej z rolą trenera z metodyki XP ukierunkowaną na zarządzanie zespołem.
  • Architekt - odpowiada ze podejmowanie decyzji projektowych, koordynuje oraz kieruje wykonywaniem czynności i artefaktów technicznych, jest również głównym projektantem. Jego rola została zaczerpnięta z metodyki RUP. Posiada także elementy trenera z metodyki XP ukierunkowanego na aspekty techniczne.
  • Analityk - odpowiada ze biznesową analizę projektu i kontroluje ryzyko związane z funkcjonalnością oraz jakością produktów. Rola ta pochodzi z metodyki RUP oraz zawiera funkcję klienta z metodyki XP.
  • Programiści

Cykl życia projektu

Metodyka XPrince łącze w sobie wybrane elementy cyklu życia projektu z metodyk XP, PRINCE2 oraz RUP.

Rozpoczęcie projektu Inicjacja projektu Elaboracja
Wydanie 1
Przyrost 1.1 Przyrost 1.2
...
Wydanie k
Przyrost k.1 Przyrost k.2
Zamknięcie projektu

Rys. Schemat cyklu życia projektu w metodyce XPrince

Cele w poszczególnych fazach życia projektu:

  • Rozpoczęcie projektu - wybór zespołu zarządzającego projektem, przygotowanie wizji i koncepcji systemu, zaplanowanie fazy Inicjacji projektu.
  • Inicjacja projektu - faza przeprowadzana przez Menadżera Projektu, Analityka i Architekta, przygotowanie i dostarczenie planu projektu, propozycja wstępnej architektury, dopracowanie biznesowego uzasadnienia projektu, stworzenie środowiska organizacyjnego, wyznaczenie kanałów komunikacyjnych, sporządzenie listy potrzebnych narzędzi, zaplanowanie fazy Elaboracji. Faza ta łączy elementy fazy Rozpoczęcia z metodyki RUP oraz z Inicjacji z metodyki PRINCE2.
  • Elaboracja - faza dotycząca głównie architektury, Architekt przedstawia opracowania mechanizmów architektonicznych z uwzględnieniem dotyczących ich ryzyk i przygotowuje szkielet projektu, Analityk doprecyzowuje wymagania projektu, a Menadżer projektu dopracowuje plan projektu.
  • Wydanie - etap ten zawiera kilka przyrostów (iteracji), które kończą się fazą tranzycji. Architekt wspólnie z Programistami produkuje kod oraz implementuje przypadki testowe, Analityk przygotowuje testy akceptacyjne i sprawdza zgodność kodu z wymaganiami. Po tranzycji następuje wdrożenie produktu lub zmian i przekazanie kolejnej wersji użytkownikom końcowym. Faza ta jest podobna do fazy Wydania z metodyki XP.
  • Zamknięcie projektu - następuje sprawdzenie kompletności projektu, przygotowanie dokumentacji technicznej oraz ocena projektu. Faza wzorowana na metodyce PRINCE2

Przypisy

  1. ↑ Mastalerz M. W., (2015), Zeszyty Naukowe Uniwersytetu Szczecińskiego. Studia Informatica, str.81
  2. ↑ Miłosz M., Borys M., Plechawska-Wójcik M., (2011), Współczesne technologie informatyczne. Metodyki zwinne wytwarzania oprogramowania, Politechnika Lubelska, str. 19
  3. ↑ Trąbka J., (2011), Zarządzanie projektem wdrożeniowym systemu klasy ERP - autorska metodyka, Metody Informatyki Stosowanej, Szczecin, str.93
  4. ↑ Olek Ł., Nawrocki J., Jasiński M., Paliświat B., Walter B., Pietrzak B., Godek P., Równowaga między zwinnością a dyscypliną z wykorzystaniem XPrince, Politechnika Poznańska, str. 8

Bibliografia

Autor: Łukasz Sęk

Źródło: „https://mfiles.pl/pl/index.php?title=Metodyka_XPrince&oldid=121606”