Metodyka XPrince: Różnice pomiędzy wersjami
Nie podano opisu zmian |
m (cleanup bibliografii i rotten links) |
||
(Nie pokazano 21 wersji utworzonych przez 3 użytkowników) | |||
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'', | '''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'', s. 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, s. 19</ref>. Podobnie jak w metodyce [[Metodyka PRINCE II|PRINCE2]] w XPrince do kontroli projektu dochodzi na różnych poziomach. | ||
==TL;DR== | |||
Metodyka XPrince jest adaptacyjnym zarządzaniem projektami zwinnych metodyk wytwarzania oprogramowania, która łączy elementy Metodyki Extreme Programming, Metodyki PRINCE II oraz Rational Unified Process. Metodyka zakłada zbalansowanie zwinności i dyscypliny, oraz zawiera elementy kontroli i dokumentacji. Twórcą metodyki jest prof. Jerzy Nawrocki z Politechniki Poznańskiej. Metodyka ma płaską strukturę zespołu projektowego i łączy wybrane elementy cyklu życia projektu z różnych metodyk. | |||
==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. | 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, s. 93</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, | 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, s. 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. | ||
<google>n</google> | |||
==Zespół projektowy== | ==Zespół projektowy== | ||
W metodyce XPrince | [[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 28: | Linia 33: | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| '''Rozpoczęcie projektu''' || '''Inicjacja projektu''' || '''Elaboracja''' || | | '''Rozpoczęcie projektu''' || '''Inicjacja projektu''' || '''Elaboracja''' || | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| '''Wydanie 1''' | | '''Wydanie 1''' | ||
|- | |- | ||
| Przyrost 1.1 || Przyrost 1.2 | | [[Przyrost]] 1.1 || Przyrost 1.2 | ||
|} | |} | ||
|| ... || | || ... || | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| '''Wydanie ''k | | '''Wydanie ''k''' | ||
|- | |- | ||
| Przyrost ''k''.1 || Przyrost ''k''.2 | | Przyrost ''k''.1 || Przyrost ''k''.2 | ||
Linia 46: | Linia 51: | ||
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]] | ||
{{infobox5|list1={{i5link|a=[[Inżynieria oprogramowania]]}} — {{i5link|a=[[Feature-Driven Development]]}} — {{i5link|a=[[Cykl życia systemu informatycznego]]}} — {{i5link|a=[[Tradycyjne zarządzanie projektem]]}} — {{i5link|a=[[Cykl życia projektu]]}} — {{i5link|a=[[Ciągła integracja]]}} — {{i5link|a=[[Scaled agile framework]]}} — {{i5link|a=[[Metodyka SCRUM]]}} — {{i5link|a=[[Metoda tworzenia systemów dynamicznych]]}} }} | |||
==Przypisy== | ==Przypisy== | ||
<references /> | <references /> | ||
==Bibliografia== | ==Bibliografia== | ||
* Mastalerz M. | <noautolinks> | ||
* Miłosz M., Borys M., Plechawska-Wójcik M. | * Mastalerz M. (2015), ''[http://wneiz.pl/nauka_wneiz/studia_inf/36-2015/si-36-75.pdf Zwinne podejście w zarządzaniu przedsiębiorstwem]'', Zeszyty Naukowe Uniwersytetu Szczecińskiego, Studia Informatica nr 36 | ||
* Młotkowski M. | * Miłosz M., Borys M., Plechawska-Wójcik M. (2011), ''[https://bc.pollub.pl/Content/673/PDF/zwinne.pdf Współczesne technologie informatyczne. Metodyki zwinne wytwarzania oprogramowania]'', Politechnika Lubelska | ||
* 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 | * Młotkowski M. (2017), ''[https://ii.uni.wroc.pl/~marcinm/dyd/zwinne/zarzadzanie.pdf Metodyki zwinne wytwarzania oprogramowania]'', wykład | ||
* Podgórski W. | * Olek Ł., Nawrocki J., Jasiński M., Paliświat B., Walter B., Pietrzak B., Godek P. (2020), ''Równowaga między zwinnością a dyscypliną z wykorzystaniem XPrince'', Politechnika Poznańska | ||
* Podgórski W. (2009), ''Metodyka XPrince'', Politechnika Wrocławska | |||
* Trąbka J. (2011), ''Zarządzanie projektem wdrożeniowym systemu klasy ERP - autorska metodyka'', Metody Informatyki Stosowanej, Szczecin | |||
</noautolinks> | |||
{{a|Łukasz Sęk}} | {{a|Łukasz Sęk}} | ||
[[Kategoria:Metodyki zarządzania projektami]] | |||
{{#metamaster:description|XPrince to metodyka wytwarzania oprogramowania, która połącza zwinność i dyscyplinę. Bazuje na XP, PRINCE2 i RUP. Zawiera elementy kontroli i dokumentacji.}} |
Aktualna wersja na dzień 17:11, 19 gru 2023
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.
TL;DR
Metodyka XPrince jest adaptacyjnym zarządzaniem projektami zwinnych metodyk wytwarzania oprogramowania, która łączy elementy Metodyki Extreme Programming, Metodyki PRINCE II oraz Rational Unified Process. Metodyka zakłada zbalansowanie zwinności i dyscypliny, oraz zawiera elementy kontroli i dokumentacji. Twórcą metodyki jest prof. Jerzy Nawrocki z Politechniki Poznańskiej. Metodyka ma płaską strukturę zespołu projektowego i łączy wybrane elementy cyklu życia projektu z różnych metodyk.
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
- Dyrektor - reprezentuje interesy inwestora
- Główny użytkownik - kieruje końcowymi użytkownikami oraz jest odpowiedzialny za użyteczność programu
- Główny dostawca - reprezentuje wykonawcę
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 |
|
... |
|
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
Metodyka XPrince — artykuły polecane |
Inżynieria oprogramowania — Feature-Driven Development — Cykl życia systemu informatycznego — Tradycyjne zarządzanie projektem — Cykl życia projektu — Ciągła integracja — Scaled agile framework — Metodyka SCRUM — Metoda tworzenia systemów dynamicznych |
Przypisy
- ↑ Mastalerz M. W., (2015), Zeszyty Naukowe Uniwersytetu Szczecińskiego. Studia Informatica, s. 81
- ↑ Miłosz M., Borys M., Plechawska-Wójcik M., (2011), Współczesne technologie informatyczne. Metodyki zwinne wytwarzania oprogramowania, Politechnika Lubelska, s. 19
- ↑ Trąbka J., (2011), Zarządzanie projektem wdrożeniowym systemu klasy ERP - autorska metodyka, Metody Informatyki Stosowanej, Szczecin, s. 93
- ↑ 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, s. 8
Bibliografia
- Mastalerz M. (2015), Zwinne podejście w zarządzaniu przedsiębiorstwem, Zeszyty Naukowe Uniwersytetu Szczecińskiego, Studia Informatica nr 36
- Miłosz M., Borys M., Plechawska-Wójcik M. (2011), Współczesne technologie informatyczne. Metodyki zwinne wytwarzania oprogramowania, Politechnika Lubelska
- Młotkowski M. (2017), Metodyki zwinne wytwarzania oprogramowania, wykład
- Olek Ł., Nawrocki J., Jasiński M., Paliświat B., Walter B., Pietrzak B., Godek P. (2020), Równowaga między zwinnością a dyscypliną z wykorzystaniem XPrince, Politechnika Poznańska
- Podgórski W. (2009), Metodyka XPrince, Politechnika Wrocławska
- Trąbka J. (2011), Zarządzanie projektem wdrożeniowym systemu klasy ERP - autorska metodyka, Metody Informatyki Stosowanej, Szczecin
Autor: Łukasz Sęk