Wykład nr 6
This commit is contained in:
Jacek Marciniak
parent
12df1c5348
commit
6d73c41f54
681
.ipynb_checkpoints/06_pmbok-checkpoint.ipynb
Normal file
681
.ipynb_checkpoints/06_pmbok-checkpoint.ipynb
Normal file
@ -0,0 +1,681 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "raw",
|
||||
"metadata": {},
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 6. <i>Zarządzania projektem informatycznym w metodyce PMBOK </i>[wykład]</h2> \n",
|
||||
"<h3>Jacek Marciniak (2022)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1. Dlaczego konieczne jest zarządzanie projektem informatycznym?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Czy tworzenie oprogramowania jest proste?\n",
|
||||
"\n",
|
||||
"Zjawisko zwane \"Kryzysem oprogramowania\":\n",
|
||||
"- Początki informatyki to era tworzenia małych programów przez ich bezpośrednich odbiorców.\n",
|
||||
"- Rozwój informatyki w połowie lat sześćdziesiątych doprowadził do tworzenia znacznie bardziej złożonych systemów przez profesjonalną grupę zawodową – programistów.\n",
|
||||
"- Podjęte zostały próby tworzenia złożonych systemów informatycznych, których tworzeniem zajmowały się duże zespoły programistyczne. \n",
|
||||
"- Wiele z tych projektów nie zostało nigdy ukończonych, inne znaczenie przekroczyły założony czas i budżet oraz były niezadowalającej jakości.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Kryzys oprogramowania w rozkwicie – lata 90-te XX wieku\n",
|
||||
"\n",
|
||||
"Zjawisko kryzysku oprogramowania zostało zauważone jako negatywnie wpływające na rynek produkcji oprogramowania w latach 90-tych XX wieku:\n",
|
||||
"- W latach dziewięćdziesiątych 90% znaczących firm programistycznych w USA przyznawało się do opóźnień w tworzeniu oprogramowania.\n",
|
||||
"- Przyjęło się, że w systemach informatycznych błędy w oprogramowaniu stają się dominujące nad błędami sprzętowymi.\n",
|
||||
"- Niepowodzeniem kończy się 31% projektów informatycznych, a dalsze 53% projektów wymaga zwiększenia czasu, budżetu, bądź ograniczenia założonych funkcjonalności lub jakości. Jedynie 16% projektów kończy się na czas!\n",
|
||||
"- Wg. danych z 1995 roku połowa ukończonych projektów informatycznych posiadało w chwili ukończenia mniej niż 42% pierwotnie założonych funkcjonalności.\n",
|
||||
"- W 1995 roku projekty skasowane w USA kosztowały 81 mld USD.\n",
|
||||
"\n",
|
||||
"Niestety,ale prawie 30 lat później powyższe problemy nadal występują!\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Przyczyny kryzysu oprogramowania\n",
|
||||
"\n",
|
||||
"Przyczyny wynikające z charakteru projektów informatycznych:\n",
|
||||
"- Duża złożoność systemów informatycznych\n",
|
||||
"- Niepowtarzalność poszczególnych przedsięwzięć informatycznych\n",
|
||||
"- Nowe technologie wykorzystywane do tworzenia oprogramowanie rozpowszechniają się bardzo szybko. Często docierają w stanie niedojrzałym powodując frustrację twórców oprogramowania\n",
|
||||
"- Presja wymuszająca bardzo szybką dostawę gotowych systemów. Projekty 4-8 letnie są nieakceptowalne!\n",
|
||||
"- Poziom świadomości współczesnych użytkowników powodują wzrost wymagań odnośnie złożoności programów\n",
|
||||
"- Obecne systemy to w wielu wypadkach integracja wielu komponentów pochodzących od różnych producentów\n",
|
||||
"- Długi i kosztowny cykl tworzenia oprogramowania, wysokie prawdopodobieństwo niepowodzenia projektu programistycznego.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Przyczyny wynikające ze złego prowadzenia projektów:\n",
|
||||
"\n",
|
||||
"- Specyfikacje są niekompletne i niejednoznaczne.\n",
|
||||
"- Za mało planowania.\n",
|
||||
"- Zła komunikacja.\n",
|
||||
"- Złe oszacowania.\n",
|
||||
"- Brak jasno określonych zakresów odpowiedzialności.\n",
|
||||
"- Mało uwagi poświęconej problemom jakości.\n",
|
||||
"- Za mało udziału użytkowników końcowych.\n",
|
||||
"- Nieświadomi zagrożeń kierownicy projektów.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Metody walki z kryzysem oprogramowania\n",
|
||||
"\n",
|
||||
"Kryzys oprogramowania można minimalizować poprzez:\n",
|
||||
"- Korzystanie z metod inżynierii oprogramowania,\n",
|
||||
"- Korzystanie z metodyk zarządzania projektami.\n",
|
||||
"\n",
|
||||
"Inżynieria oprogramowania jest wiedzą techniczną dotycząca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu – oprogramowania. Inżynieria oprogramowania zapewnia:\n",
|
||||
"- Techniki i narzędzi ułatwiające pracę nad złożonymi systemami,\n",
|
||||
"- Metody wspomagające analizę nieznanych problemów oraz ułatwiające wykorzystanie wcześniejszych doświadczeń,\n",
|
||||
"- Usystematyzowanie procesu wytwarzania oprogramowania, tak aby ułatwić jego planowanie i monitorowanie.\n",
|
||||
"\n",
|
||||
"Metodyki zarządzania projektami określają zasady na jakich należy skutecznie prowadzić projekt informatyczny.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2. Czym jest projekt i zarządzanie projektem informatycznym\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Czym jest projekt informatyczny\n",
|
||||
"\n",
|
||||
"Projekt to sekwencja unikatowych, złożonych i powiązanych ze sobą aktywności, które mają doprowadzić do określonego celu i muszą zostać zrealizowane w określonym okresie czasu, w założonym budżecie oraz zgodnie z określoną specyfikacją.\n",
|
||||
"\n",
|
||||
"Gdzie:\n",
|
||||
"\n",
|
||||
"1) Sekwencja aktywności:\n",
|
||||
"- Jako aktywność rozumie się określony zestaw zadań do wykonania,\n",
|
||||
"- Aktywności powinny być realizowane w sposób uporządkowany – w sekwencji,\n",
|
||||
"- Sekwencja wykonywania zadań powinna wynikać ze specyfikacji technicznej, a nie z uwarunkowań zarządczych,\n",
|
||||
"- Przy określaniu sekwencji aktywności należy określić : a) Co jest potrzebne jako wejście do danej aktywności aby rozpocząć jej realizację, b) jakie aktywności wygenerują jako produkt to wejście.\n",
|
||||
"\n",
|
||||
"2) Aktywności są unikatowe:\n",
|
||||
"- Każda z aktywności jest niepowtarzalna tzn. nie zdarzyła się nigdy wcześniej, ani nie zdarzy się nigdy później,\n",
|
||||
"- Na podobne (potencjalnie powtarzalne) aktywności wpływa zawsze tyle czynników zewnętrznych (np. opóźniła się realizacja innego fragmentu systemu, rozchorował się kluczowy członek zespołu, uszkodzeniu uległ sprzęt), że aktywności takie nigdy nie będą powtarzalne.\n",
|
||||
"\n",
|
||||
"3) Aktywności są złożone – każda z czynności wykonywanych przez zespoły programistyczne to czynność złożona (np. zaprojektowanie architektury bazy danych, zaprojektowanie interfejsu użytkownika).\n",
|
||||
"\n",
|
||||
"4) Aktywności są powiązane:\n",
|
||||
"- Istnieje logiczny i techniczny związek pomiędzy poszczególnymi parami aktywności,\n",
|
||||
"- Istnieje określona ścieżka realizacji aktywności, która doprowadzi do ukończenia projektu,\n",
|
||||
"- Wyjście jednej aktywności jest zawsze wejściem do kolejnej.\n",
|
||||
"\n",
|
||||
"5) Projekt prowadzi do określonego celu:\n",
|
||||
"- Każdy projekt ma tylko jeden cel,\n",
|
||||
"- Duże projekty mogą być podzielone na podprojekty z różnymi celami, jednak każdy z podprojektów jest również projektem,\n",
|
||||
"- Podział na podprojekty ułatwia zarządzanie całym projektem.\n",
|
||||
"\n",
|
||||
"6) Projekt musi zostać zrealizowany w określonym czasie:\n",
|
||||
"- Termin narzucony jest przez zarząd projektu, bądź zewnętrznie przez klienta,\n",
|
||||
"- Projekt jest **zakończony** w określonym terminie niezależnie od tego czy prace zostały zakończone czy nie!\n",
|
||||
"\n",
|
||||
"7) Projekt musi być wykonany w ramach założonego budżetu:\n",
|
||||
"- Każdy projekt posiada określony zasoby dedykowane do realizacji projektu: ludzie, pieniądze, urządzenia,\n",
|
||||
"- Zasoby są przez kierownika projektu traktowane jako zasoby trwałe (tzn. dostępne wtedy kiedy są potrzebne), chociaż przez zarząd firmy mogą być traktowane jako zasoby rotacyjne (tzn. przesuwane pomiędzy różnymi projektami).\n",
|
||||
"\n",
|
||||
"8) Projekt musi być wykonany zgodnie ze specyfikacją:\n",
|
||||
"- Odbiorca projektu oczekuje, że będzie on spełniał pewne wymagania funkcjonalne zapisane w specyfikacji,\n",
|
||||
"- Kierownik projektu przyjmuje że specyfikacja jest niezmienna w określonym przyroście,\n",
|
||||
"- Zmienność specyfikacji jest stałym elementem każdego projektu oraz wyzwaniem dla każdego kierownika projektu.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Interesariusze projektu\n",
|
||||
"\n",
|
||||
"Interesariusze (ang. stakeholders) to osoby, bądź organizacje, które są zainteresowane wynikami projektu. Osoby te są:\n",
|
||||
"- Aktywnie zaangażowane w realizację projektu, bądź\n",
|
||||
"- Mają coś do zyskania, bądź stracenia gdy wynik projektu zostanie osiągnięty.\n",
|
||||
"\n",
|
||||
"Kluczowi interesariusze mogą doprowadzić do sukcesu, bądź porażki projektu niezależnie od tego czy wszystkie cele projektu zostały osiągnięte bądź nie.\n",
|
||||
"\n",
|
||||
"Jeżeli kluczowi interesariusze projektu nie są zadowoleni **NIKT** nie jest zadowolony.\n",
|
||||
"\n",
|
||||
"Konieczne jest zidentyfikowanie wszystkich interesariuszy przed rozpoczęciem projektu – nie rozpoznanie na czas potrzeb kluczowego interesariusza może doprowadzić do porażki projektu!\n",
|
||||
"\n",
|
||||
"Podstawowi interesariusze projektu:\n",
|
||||
"- Sponsor projektu – osoba, bądź instytucja finansująca projekt.\n",
|
||||
"- Klient – odbiorca produktów projektu,\n",
|
||||
"- Kierownik projektu – osoba odpowiedzialna za prowadzenie projektu,\n",
|
||||
"- Zespół projektowy – osoby realizujące projekt,\n",
|
||||
"- Dostawcy – osoby, bądź instytucje współpracujące przy projekcie,\n",
|
||||
"- Biuro projektowe – osoby wspierające organizacyjnie projekt,\n",
|
||||
"- Kadra zarządzająca instytucji klienta – osoby pośrednio zainteresowane produktami projektu.\n",
|
||||
"\n",
|
||||
"Interesariusze bardzo często mają sprzeczne interesy. Kierownik projektu każdorazowo odpowiedzialny jest za identyfikowanie i rozwiązywanie konfliktu interesów.\n",
|
||||
"\n",
|
||||
"W przypadku wątpliwości co do sprzecznych interesów decyzje powinny być zawsze podejmowane na korzyść **klienta**!\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Parametry projektu\n",
|
||||
"\n",
|
||||
"Dla każdego projektu można wyróżnić 5 składowych:\n",
|
||||
"- Zakres,\n",
|
||||
"- Jakość,\n",
|
||||
"- Koszt,\n",
|
||||
"- Czas,\n",
|
||||
"- Zasoby.\n",
|
||||
"\n",
|
||||
"Składowe te pozostają między sobą w zależności – zmiana w jednej składowej pociąga zawsze zmianę w innej składowej. Aby projekt zakończył się sukcesem wszystkie te składowe muszą pozostawać zrównoważone!\n",
|
||||
"\n",
|
||||
"1) Zakres projektu:\n",
|
||||
"- Zakres projektu określa ramy w których realizowany jest projekt; określa co ma być zrobione, ale również to co ma nie być zrobione,\n",
|
||||
"- W systemach informatycznych zakres zapisywany jest w postaci wymagań funkcjonalnych, bądź każdy inny dokument określający czego dotyczy projekt (dokumentacja rozpoczęcia projektu, formularz projektowy),\n",
|
||||
"- Dokument określający zakres projektu jest podstawą wszystkich prac prowadzonych w projekcie. Krytyczne jest, aby zakres projektu określony został w sposób poprawny. \n",
|
||||
"- Zakres projektu będzie się zmieniał: nie jesteśmy w stanie określić kiedy i w jakim stopniu, ale pewne jest że w każdym projekcie zmiany te się pojawią. Ważne jest więc szybkie wykrycie tych zmian oraz wdrożenie ich do realizacji. \n",
|
||||
"\n",
|
||||
"2) Jakość:\n",
|
||||
"\n",
|
||||
"Dwa rodzaje jakości należy uwzględniać w każdym projekcie:\n",
|
||||
"- Jakość produktu – dotyczy jakości produktu końcowego projektu\n",
|
||||
"- Jakość procesu – dotyczy procesu prowadzenia projektu. Zagadnienie dotyczy tego w jaki sposób przebiega projekt, czy proces ten wymaga usprawnień i modyfikacji.\n",
|
||||
"\n",
|
||||
"W każdym projekcie wskazane jest, aby uruchomić procedury utrzymania jakości. Podejście takie zapewnia:\n",
|
||||
"- Zwiększenie satysfakcji klienta projektu,\n",
|
||||
"- Zwiększenie efektywnego wykorzystania zasobów oraz zmniejszenie kosztów.\n",
|
||||
"\n",
|
||||
"3) Koszt:\n",
|
||||
"- Koszt projektu jest najpoważniejszą składową każdego projektu. \n",
|
||||
"- Realizacja projektu dokonuje się zawsze w ramach przypisanego budżetu, niezależnie od tego czy projekt jest realizowany na potrzeby zewnętrzne (tzn. dla klienta zewnętrznego), czy też w ramach danej organizacji.\n",
|
||||
"- Bardzo często przy rozpoczynaniu projektu klient jest skłonny przeznaczyć na ten projekt określoną kwotę. Ważne jest, aby rozpoznać taką sytuację i w sytuacji w której jest za niska względem realnych spodziewanych kosztów wykonać tylko określoną część zadań projektowych.\n",
|
||||
"- Poprawne oszacowanie kosztu projektu jest krytyczne w sytuacjach sformalizowanych umowami. Błędy w szacunku mogą uniemożliwić realizację projektu.\n",
|
||||
"\n",
|
||||
"4) Czas:\n",
|
||||
"- Dla każdego projektu określany jest termin w którym projekt powinien się zakończyć. \n",
|
||||
"- W wielu sytuacjach koszt i czas są odwrotnie powiązane ze sobą: jeżeli chcemy skrócić czas realizacji projektu, wzrośnie nam jego koszt.\n",
|
||||
"- Czas postrzegany jako zasób posiada bardzo ciekawą charakterystykę: niezależnie od tego czy jest używany jest zawsze konsumowany! Celem kierownika projektu jest więc jak najbardziej efektywne wykorzystanie czasu. \n",
|
||||
"- Czas „przyszły” może być traktowany jako zasób zbywalny tzn. może stać się przedmiotem handlu w ramach projektu, bądź pomiędzy projektami.\n",
|
||||
"\n",
|
||||
"5) Zasoby:\n",
|
||||
"- Zasoby to byty takie jak ludzie, wyposażenie, powierzchnie biurowe, sprzęt. Zasoby traktujemy jako dobra zbywalne o ograniczonej dostępności, które podlegają harmonogramowaniu, mogą być zbywane, bądź nabywane. \n",
|
||||
"- Niektóre zasoby są dostępne zawsze, inne dostępne są tylko w określonym okresie czasu. Niezależnie od tego zasoby są kluczowym elementem harmonogramowania aktywności projektu.\n",
|
||||
"- W projektach informatycznych podstawowym zasobem są ludzie oraz dostępność czasu procesorów (np. do testowania systemu).\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Trójkąt zakresu\n",
|
||||
"\n",
|
||||
"Zależności pomiędzy parametrami projektu obrazujące konieczność zachowania równowagi pomiędzy nimi obrazuje następujący Trójkąt zakresu:\n",
|
||||
"\n",
|
||||
"![img](./obrazy/trojkat_zakresu.png \"Trójkąt zakresu\")\n",
|
||||
"\n",
|
||||
"W podejściu tym plan projektu zakłada określony czas, koszty i zasoby na zrealizowanie projektu o wyspecyfikowanym zakresie i określonej jakości. Projekt jest zrównoważonym bytem uwzględniającym wszystkie pięć wymienionych składowych. Równowaga ta nie będzie nigdy trwała zbyt długo!!!\n",
|
||||
"\n",
|
||||
"Trójkąt zakresu projektu obrazuje jak w trakcie realizacji projektu zmiany jednej ze składowych wpływają na inne składowe, np..:\n",
|
||||
"- Zwiększenie zakresu (np. na życzenie klienta) wymagało będzie zwiększenia dostępności zasobów i zwiększenia kosztów, bądź czasu,\n",
|
||||
"- Skrócenie terminu (np. w odpowiedzi na żądanie klienta) wymagało będzie zmniejszenia zakresu, bądź jakości lub też zwiększenia kosztu i dostępności zasobów,\n",
|
||||
"- Zmiana dostępności zasobów (np. opuszczenie projektu przez kluczowego programistę) uniemożliwi osiągnięcie zaplanowanego zakresu, itd.\n",
|
||||
"\n",
|
||||
"Kto kontroluje poszczególne składowe trójkąta:\n",
|
||||
"- Kierownik projektu: użycie zasobów, czas realizacji projektu,\n",
|
||||
"- Zarząd projektu: koszt oraz użycie zasobów\n",
|
||||
"- Klient: zakres, jakość i termin zakończenia projektu.\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zarządzanie projektem\n",
|
||||
"\n",
|
||||
"Zarządzanie projektem to zestaw narzędzi i technik wykonywanych przez ludzi, aby opisywać, organizować oraz monitorować pracę aktywności składających się na projekt.\n",
|
||||
"\n",
|
||||
"Kierownicy projektu to osoby odpowiedzialne za zarządzanie procesami realizowanymi w ramach projektu, stosujące narzędzia i techniki, aby zrealizować cele projektu.\n",
|
||||
"\n",
|
||||
"Zarządzanie projektem to proces który:\n",
|
||||
"- Zakłada planowanie, realizowanie planów oraz kontrolowanie przyrostu i efektywności prowadzonych prac,\n",
|
||||
"- Obejmuje identyfikowanie wymagań, określanie celów projektu oraz równoważenie składowych projektu,\n",
|
||||
"- Obejmuje czynności mające na celu rozpoznanie celów interesariuszy\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Kierownik projektu (ang. Project Manager; PM)\n",
|
||||
"\n",
|
||||
"Kierownik projektu to osoba, która powinna posiadać różne kompetencje niezbędne do prawidłowego prowadzenia projektu informatycznego. Bardzo często kierownikami projektu zostają osoby o wykształceniu technicznym, jednak wiadomości techniczne nie są krytyczne w pracy kierownika projektu.\n",
|
||||
"\n",
|
||||
"Podstawowe kompetencje kierownika projektu:\n",
|
||||
"- Zdolności komunikacji,\n",
|
||||
"- Zdolności organizacyjne i planistyczne,\n",
|
||||
"- Zdolności budżetowania,\n",
|
||||
"- Zdolności rozwiązania konfliktów,\n",
|
||||
"- Zdolności negocjacji i wpływania na innych,\n",
|
||||
"- Zdolności przywódcze,\n",
|
||||
"- Zdolności budowania zespołu i zdolności motywacji.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3. Metodyka PMBOK: cykl życia projektu, a procesy zarządzania projektem\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zarządzanie projektem w podejściu tradycyjnym\n",
|
||||
"\n",
|
||||
"Zarządzanie projektami w podejściu tradycyjnym bazuje na filozofii prowadzenia projektu w oparciu gotowy zestaw rozwiązań uruchamianych w określonym momencie realizacji projektu. Podejść do realizacji projektów w podejściu tradycyjnym jest wiele, różnią się one między sobą w mniejszym lub większym zakresie.\n",
|
||||
"\n",
|
||||
"Obecnie jedną z najbardziej rozpowszechnionych metodyk tradycyjnego zarządzania projektem, w tym zarządzania projektem informatycznym, jest metodyka **Project Management Body of Knowledge (PMBOK)** opracowana przez **Project Management Institute (PMI)**."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Fazy projektu i cykl życia projektu\n",
|
||||
"\n",
|
||||
"We wszystkich projektach można wyróżnić pewne fazy ich realizacji. W najprostszym podejściu wyróżniamy takie fazy jak: rozpoczęcie, realizacja, zakończenie. Ilość faz zależy od złożoności projektu oraz dziedziny przemysłu w której jest realizowany (budownictwo, produkcja maszyn, projekty informatyczne).\n",
|
||||
"\n",
|
||||
"Cyklem życia projektu nazywamy wszystkie fazy projektu występujące podczas jego realizacji.\n",
|
||||
"Fazy projektu i cykl życia projektu odnoszą się do pracy, która jest realizowana w projekcie w celu osiągnięcia celów projektu. W projektach informatycznych **fazy projektu** są opisywane **cyklem życia oprogramowania**. Przykładami takiego cyklu może być model kaskadowy, Unified Process, bądź SCRUM. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Procesy zarządzania projektem\n",
|
||||
"\n",
|
||||
"Zarządzanie projektem to zestaw czynności polegających na planowaniu, szacowaniu i kontrolowaniu pracy zespołów ludzkich w celu osiągnięcia oczekiwanego celu w zadanym okresie czasu, przy zachowaniu określonego budżetu, w oparciu o określoną specyfikację.\n",
|
||||
"\n",
|
||||
"Zarządzanie projektem jest realizowane poprzez tzw. procesy zarządzania projektem (ang. project management processes). Procesy są wykonane przez ludzi i podobnie jak fazy projektu są powiązane pomiędzy sobą. W modelu tradycyjnym wyróżnia się następujące **grupy procesów zarządzania projektem** (inaczej **fazy zarządzania projektem**):\n",
|
||||
"- Rozpoczęcie,\n",
|
||||
"- Planowanie,\n",
|
||||
"- Wykonywanie,\n",
|
||||
"- Monitorowanie i kontrola,\n",
|
||||
"- Zamykanie.\n",
|
||||
"\n",
|
||||
"Fazy projektu i cykl życia projektu to nie to samo co procesy zarządzania projektem:\n",
|
||||
"- **Fazy projektu i cykl życia projektu** dotyczą czynności które muszą być wykonane aby osiągnąć cel projektu (czynności są realizowane przez zespoły wykonawcze zaangażowane w realizację projektu),\n",
|
||||
"- **Procesy zarządzania projektem** dotyczą aktywności prowadzonych podczas zarządzania projektem (czynności są realizowane przez osoby zarządzające projektem – przeważnie kierownika projektu). \n",
|
||||
"\n",
|
||||
"Każdy z projektów musi przejść przez fazę Zamykania. Dotyczy to również tych projektów, które zostały przerwane.\n",
|
||||
"\n",
|
||||
"1) Fazy zarządzania projektem: **Rozpoczęcie**\n",
|
||||
"\n",
|
||||
"W ramach fazy Rozpoczęcia definiowane są prace, które muszą być zrealizowane w ramach projektu oraz określane są zakresy odpowiedzialności w projekcie. Faza Rozpoczęcia ma doprowadzić do określenia zakresu projektu. Aby tego dokonać należy zrealizować następujące prace:\n",
|
||||
"- Wyspecyfikować problemy które zostaną rozwiązane / bądź korzyści które zostaną osiągnięte po zrealizowaniu projektu,\n",
|
||||
"- Określić cel projektu,\n",
|
||||
"- Określić warunki, które muszą zajść aby osiągnąć cel projektu,\n",
|
||||
"- Określić kryteria oceny tego czy projekt zakończył się sukcesem,\n",
|
||||
"- Wyspecyfikować warunki, zagrożenia, bądź przeszkody które mogą wpłynąć na sukces końcowy projektu.\n",
|
||||
"\n",
|
||||
"Zakres projektu jest zapisywany w dokumencie projektowym fazy rozpoczęcia na podstawie którego podjęte będą decyzje o rozpoczęciu projektu. Dokument projektowy tworzony jako produkt fazy Rozpoczęcia występuje w różnych postaciach: \n",
|
||||
"- Karta projektu, \n",
|
||||
"- Specyfikacja projektu, \n",
|
||||
"- Specyfikacja zakresu, \n",
|
||||
"- Początkowa definicja projektu, \n",
|
||||
"- Specyfikacja zakresu pracy, Protokół uzgodnień. \n",
|
||||
"\n",
|
||||
"Dokument taki jest często uzupełniany wymagane przez klienta do rozpoczęcia prac przy projekcie:\n",
|
||||
"- Analiza ryzyka,\n",
|
||||
"- Analiza korzyści,\n",
|
||||
"- Zwrot z inwestycji.\n",
|
||||
"\n",
|
||||
"2) Fazy zarządzania projektem: **Planowanie**\n",
|
||||
"\n",
|
||||
"Planowanie przez wielu członków zespołu projektowego jest traktowane jako niepotrzebna strata czasu ponieważ jest elementem ciągle się zmieniającym, nigdy nie aktualnym. Plany są jednak niezbędne aby w lepszy sposób rozpocząć i prowadzić projekt. \n",
|
||||
"Plany powinny być postrzegane jako byty dynamiczne tzn. takie które podlegają zmianom. Kierownik projektu powinien spodziewać się, że plany mogą ulec zmianie. Plany zapewniają nam:\n",
|
||||
"- Zmniejszenie niepewności co do przebiegu projektu,\n",
|
||||
"- Zwiększenie rozumienia celów projektu,\n",
|
||||
"- Zwiększenie efektywności prowadzenia projektu. \n",
|
||||
"\n",
|
||||
"Wynikiem fazy planowania jest:\n",
|
||||
"- Szczegółowy opis aktywności do wykonania,\n",
|
||||
"- Zasoby niezbędne do zrealizowania tych aktywności,\n",
|
||||
"- Harmonogram realizacji projektu,\n",
|
||||
"- Szacowany koszt i data zakończenia projektu.\n",
|
||||
"\n",
|
||||
"Poszczególne składowe projektu mogą ulegać zmianie. Podczas tworzenia planów należy przewidywać możliwe zmiany składowych planu, np.:\n",
|
||||
"- Jeżeli aktywność projektu zakończy się wcześniej lub później niż zaplanowano w jaki sposób rozdysponować zasoby?\n",
|
||||
"- Jeżeli jedna aktywność zakończy się z dużym opóźnieniem, czy istnieje możliwość takiego relokowania zasobów, aby zminimalizować wpływ tego opóźnienia na cały projekt?\n",
|
||||
"- W jaki sposób skracać czasy realizacji, aby unikać konfliktów wykorzystania kluczowych zasobów?\n",
|
||||
"- W jaki sposób zasoby mogą być relokowane pomiędzy projektami, aby unikać opóźnień w poszczególnych projektach?\n",
|
||||
"\n",
|
||||
"3) Fazy zarządzania projektem: **Wykonywanie**\n",
|
||||
"\n",
|
||||
"Faza Wykonywania dotyczy upoważnienia zespołu projektowego do realizacji zadań zapisanych w planie projektu. Wykonywanie planu obejmuje następujące aktywności:\n",
|
||||
"- Określenie zasobów, które muszą być dostępne aby zrealizować określoną aktywność projektu,\n",
|
||||
"- Przypisanie wykonawców do danej aktywności,\n",
|
||||
"- Określenie harmonogramu realizacji określonej aktywności,\n",
|
||||
"- Uruchomienie realizacji planu.\n",
|
||||
"\n",
|
||||
"Ważnym elementem fazy wykonywania jest określenie zespołu który będzie odpowiedzialny za realizację poszczególnych aktywności projektu. Kluczowi członkowie zespołu są określani w fazie Planowania, w fazie Wykonywania są identyfikowani pozostali członkowie zespołu. W dużych instytucjach zespoły wykonawcze są alokowane w miarę potrzeb wynikających z przebiegu projektu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"4) Faza zarządzania projektem: **Monitorowanie i kontrola**\n",
|
||||
"\n",
|
||||
"Podstawowym założeniem każdego projektu jest to, że niezależnie od zaangażowania i kompetencji zespołów wykonawczych przyjęty plan nie będzie realizowany! **Opóźnienia są nierozerwalną składową każdego projektu!** Kierownik projektu musi mieć więc wypracowany system, który pozwoli mu na monitorowanie przebiegu projektu. System monitoringu powinien pokazywać mu prace wykonane w stosunku do prac zaplanowanych. \n",
|
||||
"\n",
|
||||
"Monitorowania i kontrola obejmuje:\n",
|
||||
"- Określenie systemu raportowego pokazującego przyrosty w projekcie,\n",
|
||||
"- Określenie procesu rozwiązywania problemów,\n",
|
||||
"- Monitorowanie przyrostu projektu względem planu,\n",
|
||||
"- Zmian w planach projektu.\n",
|
||||
"\n",
|
||||
"5) Faza zarządzania projektem: **Zamykanie**\n",
|
||||
"\n",
|
||||
"Faza zamykania projektu pozwala na określenie, że projekt się zakończył oraz (w sytuacji sukcesu) dostarczenie wyników projektu klientowi. W trakcie fazy zamykania oceniany jest przebieg projektu w celu usprawnienia procesu w przyszłych projektach. Ocenia się następujące elementy projektu:\n",
|
||||
"- Czy produkty projektu spełniają oczekiwania klienta?\n",
|
||||
"- Czy produkty projektu spełniają oczekiwania kierownika projektu?\n",
|
||||
"- Czy zespół zakończył projekt zgodnie z założonym planem?\n",
|
||||
"- Czy przyjęta metodologia prowadzenia projektu sprawdziła się?\n",
|
||||
"- Czego dana organizacja może się nauczyć z zakończonego projektu?\n",
|
||||
"\n",
|
||||
"Faza ta jest często pomijana. Uniemożliwia to wyciągnięcie wniosków z projektu oraz usprawnienie procesów realizacji przyszłych projektów.\n",
|
||||
"\n",
|
||||
"Aktywności realizowane w trakcie zamykania projektu:\n",
|
||||
"- Uzyskanie akceptacji klienta,\n",
|
||||
"- Zainstalowanie produktów projektu,\n",
|
||||
"- Ukończenie dokumentacji projektowej,\n",
|
||||
"- Uzyskanie audytu po-wdrożeniowego,\n",
|
||||
"- Napisanie raportu zamknięcia projektu,\n",
|
||||
"- Świętowanie zakończenia projektu!\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Iteracyjność w procesie zarządzania projektem\n",
|
||||
"\n",
|
||||
"Realizacja projektu jest procesem iteracyjnym: po zakończeniu jednej z faz kierownik projektu oraz interesariusze projektu mogą modyfikować założenia projektu co może mieć wpływ na dalszy procesu zarządzania projektem. Możliwe scenariusze zarządzania projektem:\n",
|
||||
"\n",
|
||||
"![img](./obrazy/iteracyjnosc.png \"Iteracyjność w procesie zarządzania projektem\")"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4. Metodyka PMBOK: Obszary wiedzy w zarządzaniu projektem\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Obszary wiedzy dotyczące zarządzania projektem (ang. Project management knowledge areas) to pojęcie metodyki PMBOK, które są innym sposobem grupowania procesów zarządzania projektem. Poszczególne obszary wiedzy posiadają cechy wspólne i w oparciu o te cechy wspólne realizowane jest grupowanie. Procesy zarządzania projektem oddają porządek w jakim wykonywane są czynności realizowane w ramach prowadzenia projektu.\n",
|
||||
"\n",
|
||||
"Wyróżnione obszary wiedzy w zarządzaniu projektem:\n",
|
||||
"- Zintegrowane zarządzanie projektem,\n",
|
||||
"- Zarządzanie zakresem,\n",
|
||||
"- Zarządzanie czasem,\n",
|
||||
"- Zarządzanie kosztem,\n",
|
||||
"- Zarządzanie jakością,\n",
|
||||
"- Zarządzanie zasobami ludzkimi,\n",
|
||||
"- Zarządzanie komunikacją,\n",
|
||||
"- Zarządzanie ryzykiem,\n",
|
||||
"- Zarządzanie procesami zaopatrzenia.\n",
|
||||
"\n",
|
||||
"1) **Zintegrowane zarządzanie zakresem**\n",
|
||||
"\n",
|
||||
"Zintegrowane zarządzanie projektem dotyczy koordynowania wszystkich aspektów projektu. Obejmuje następujące procesy:\n",
|
||||
"- Budowę wstępnego zakresu projektu,\n",
|
||||
"- Budowę planu zarządzania projektem,\n",
|
||||
"- Kierowanie wykonaniem projektu\n",
|
||||
"- Monitorowanie i kontrolowanie realizacji zadań w projekcie,\n",
|
||||
"- Zintegrowana kontrola zmian w projekcie,\n",
|
||||
"- Zamykanie projektu\n",
|
||||
"\n",
|
||||
"Poszczególne procesy przynależą do różnych faz zarządzania projektem.\n",
|
||||
"\n",
|
||||
"Wykorzystywane narzędzia:\n",
|
||||
"- Metodyka Earned Value Management (EVM),\n",
|
||||
"- Oprogramowanie wspierające prowadzenie projektu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"2) **Zarządzanie zakresem**\n",
|
||||
"\n",
|
||||
"Zarządzanie zakresem projektu obejmuje zarządzanie zakresem pracy który jest niezbędny do wykonania w projekcie. Obejmuje następujące procesy:\n",
|
||||
"- Planowanie zakresu,\n",
|
||||
"- Definiowanie zakresu,\n",
|
||||
"- Tworzenie WBS (work breakdown structure),\n",
|
||||
"- Weryfikacja zakresu,\n",
|
||||
"- Kontrola zakresu.\n",
|
||||
"\n",
|
||||
"Zarządzanie zakresem projektu dotyczy:\n",
|
||||
"- Zakres produktu – czyli charakterystyki produktu tworzonego w ramach projektu; mierzony jest stopień uzyskania wymagań wyjściowych\n",
|
||||
"- Zakres projektu – zarządzanie dotyczy realizacji pracy w projekcie; mierzony stopień wykonanej pracy względem założeń.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"3) **Zarządzanie czasem**\n",
|
||||
"\n",
|
||||
"Zarządzanie czasem obejmuje szacowanie czasu realizacji poszczególnych zadań projektowych, opracowanie harmonogramu oraz monitorowanie i kontrolowanię odstępstw od harmonogramu. W szczególności obejmuje następujące procesy:\n",
|
||||
"- Definiowanie aktywności,\n",
|
||||
"- Sekwencjonowanie aktywności,\n",
|
||||
"- Szacowanie niezbędnych zasobów,\n",
|
||||
"- Szacowanie czasu trwania poszczególnych aktywności,\n",
|
||||
"- Harmonogramowanie,\n",
|
||||
"- Kontrola realizacji harmonogramu.\n",
|
||||
"- Zarządzanie czasem daje możliwość śledzenia czy aktywności projektu są realizowane zgodnie z planem oraz czy projekt zakończył się o czasie.\n",
|
||||
"\n",
|
||||
"4) **Zarządzanie kosztem**\n",
|
||||
"\n",
|
||||
"Zarządzanie kosztem pozwala na kontrolowanie tego czy projekt jest realizowany w ramach zaplanowanego budżetu. Obejmuje następujące procesy:\n",
|
||||
"- Szacowanie kosztów,\n",
|
||||
"- Budżetowanie kosztów,\n",
|
||||
"- Kontrolowanie kosztów.\n",
|
||||
"Zadanie dotyczy przede wszystkim zarządzania kosztami zasobów, jednakże wszelkie inne koszty również powinny być tutaj uwzględniane. Przy złożonych projektach może być konieczne aby przy zadaniu tym pracowała więcej niż jedna osoba, np. w kwestiach związanych z księgowością kierownik projektu może potrzebować wsparcia działu obsługi finansowej.\n",
|
||||
"\n",
|
||||
"5) **Zarządzanie jakością**\n",
|
||||
"\n",
|
||||
"Zarządzanie jakością zapewnia, że projekt spełnia oczekiwania klienta zapisane w wymaganiach. Zarządzanie obejmuje:\n",
|
||||
"- Zarządzanie jakością produktu projektu,\n",
|
||||
"- Zarządzanie jakością projektu.\n",
|
||||
"- Zarządzanie jakością obejmuje następujące procesy:\n",
|
||||
"- Planowanie jakości,\n",
|
||||
"- Wdrożenie i realizacja procedur utrzymania jakości,\n",
|
||||
"- Kontrola jakości.\n",
|
||||
"\n",
|
||||
"6) **Zarządzanie ryzykiem**\n",
|
||||
"\n",
|
||||
"W zarządzaniu projektami ryzyko to wydarzenie z przyszłości, które jeżeli zajdzie może wpłynąć pozytywnie, bądź negatywnie na projekt. W większości wypadków ryzyko rozumiane jest tradycyjnie tzn. jest powiązane ze stratami. Straty spowodowane przez ryzyko mogą być szacowane. Robi się to poprzez uwzględnienie dwóch czynników:\n",
|
||||
"- Prawdopodobieństwo, że dane zdarzenie zajdzie,\n",
|
||||
"- Skala strat jeżeli zdarzenie takie zajdzie.\n",
|
||||
"Analiza ryzyka związana z zarządzaniem projektem wymaga odpowiedzi na następujące pytania:\n",
|
||||
"- Jakie ryzyka są związane z projektem?\n",
|
||||
"- Jakie jest prawdopodobieństwo strat wynikających z tych ryzyk?\n",
|
||||
"- Ile straty takie będą kosztowały?\n",
|
||||
"- Jakie straty się pojawią jeżeli spełni się najgorszy scenariusz?\n",
|
||||
"- Jakie są rozwiązania alternatywne?\n",
|
||||
"- W jaki sposób straty mogą zostać zminimalizowane?\n",
|
||||
"- Czy rozwiązania alternatywne są obarczone ryzykiem?\n",
|
||||
"\n",
|
||||
"W projekcie zarządzamy jedynie tymi ryzykami, które mogą wpłynąć na projekt. Pomijamy inne ryzyka np. ryzyka biznesowe.\n",
|
||||
"Doświadczenie kierowników projektów mówi, że 10 podstawowych przyczyn odniesienia sukcesu przez projekt to:\n",
|
||||
"- Wsparcie zarządu,\n",
|
||||
"- Zaangażowanie klienta,\n",
|
||||
"- Doświadczenie kierownika projektu,\n",
|
||||
"- Jasne cele biznesowe projektu,\n",
|
||||
"- Zminimalizowany zakres,\n",
|
||||
"- Standardowa infrastruktura,\n",
|
||||
"- Przejrzyste wymagania,\n",
|
||||
"- Prowadzenie projektu metodami formalnymi,\n",
|
||||
"- Wiarygodne oszacowania,\n",
|
||||
"- Odpowiedni pracownicy.\n",
|
||||
"\n",
|
||||
"**Należy zatem przede wszystkim zarządzać ryzykiem w powyższych obszarach**.\n",
|
||||
"\n",
|
||||
"7) **Zarządzanie zasobami ludzkimi**\n",
|
||||
"\n",
|
||||
"Zarządzanie zasobami ludzkimi (HR – human resources) obejmują wszystkie procesy związane z zarządzaniem zespołami ludzkimi, w tym leadership, szkolenia, rozwiązywanie konfliktów, zwiększanie efektywności pracy, itp. Zarządzanie obejmuje:\n",
|
||||
"- Planowanie wykorzystania zasobów ludzkich,\n",
|
||||
"- Pozyskanie zespołów ludzkich,\n",
|
||||
"- Budowa zespołu projektowego,\n",
|
||||
"- Zarządzanie zespołem projektowym.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"8) **Zarządzanie komunikacją**\n",
|
||||
"\n",
|
||||
"Zarządzanie komunikacją obejmuje wszystkie te aktywności, które dotyczą komunikacji w projekcie. \n",
|
||||
"- Zarządzanie to obejmuje:\n",
|
||||
"- Planowanie komunikacji,\n",
|
||||
"- Dystrybucja informacji,\n",
|
||||
"- Raportowanie o postępach,\n",
|
||||
"- Zarządzanie intersariuszami.\n",
|
||||
"\n",
|
||||
"9) **Zarządzanie procesami zaopatrzenia**\n",
|
||||
"\n",
|
||||
"Zarządzanie procesami zaopatrzenia dotyczy wszystkich aktywności związanych z nabywaniem produktów niezbędnych do realizacji projektu. Proces ten obejmuje:\n",
|
||||
"- Planowanie zakupów,\n",
|
||||
"- Planowanie kontraktów,\n",
|
||||
"- Składanie zamówień,\n",
|
||||
"- Wybieranie dostawców,\n",
|
||||
"- Zarządzanie kontraktami,\n",
|
||||
"- Zamykanie kontraktów.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5. Zadania proponowane na laboratoria\n",
|
||||
"\n",
|
||||
"### Zadanie 1.\n",
|
||||
"\n",
|
||||
"Przygotuj dokument *Zakres projektu*.\n",
|
||||
"\n",
|
||||
"Zakres projektu to dokument, zawierający następujące składowe:\n",
|
||||
"- Cele projektu\n",
|
||||
"- Opis produktu oczekiwanego przez klienta\n",
|
||||
"- Wymagania projektowe\n",
|
||||
"- Granice projektu\n",
|
||||
"- Kryteria akceptacji produktu\n",
|
||||
"- Ograniczenia projektowe\n",
|
||||
"- Założenia projektowe\n",
|
||||
"- Początkowa organizacja projektu\n",
|
||||
"- Ryzyka zidentyfikowane w fazie początkowej\n",
|
||||
"- Kamienie milowe do osiągnięcia\n",
|
||||
"- Ograniczenia finansowe\n",
|
||||
"- Budżet projektu\n",
|
||||
"\n",
|
||||
"### Zadanie 2.\n",
|
||||
"\n",
|
||||
"Przygotuj strukturę WBS (ang. Work Breakdown Structure) projektu.\n",
|
||||
"\n",
|
||||
"Struktura WBS to hierarchiczna struktura opisująca pracę, która powinna zostać zrealizowana przez zespoły projektowe w celu osiągnięcia celów projektu oraz uzyskania produktów projektu. Struktura WBS pokrywa cały zakres projektu. Elementami składowymi struktury WBS są zadania do wykonania. Na strukturę WBS powinny składać się na tyle małe zadania aby możliwe było łatwe ich planowanie, realizowanie, monitorowanie oraz kontrolowanie. W PMBOK przyjmuje się, że na najniższym poziomie hierarchii struktury WBS znajduje się zawsze pakiet pracy (ang. work package).\n",
|
||||
"\n",
|
||||
"### Zadanie 3.\n",
|
||||
"\n",
|
||||
"Przygotuj harmonogram projektu w postaci diagramu Gantta lub PDM (ang. precendence diagramming method).\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Jacek Marciniak",
|
||||
"email": "jacekmar@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"org": null,
|
||||
"subtitle": "6. Metodyka PMBOK",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2022"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 1
|
||||
}
|
||||
506
.ipynb_checkpoints/08_ci_cd_uczenie_maszynowe-checkpoint.ipynb
Normal file
506
.ipynb_checkpoints/08_ci_cd_uczenie_maszynowe-checkpoint.ipynb
Normal file
@ -0,0 +1,506 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 8. <i>Ciągła integracja i ewaluacja w projektach opartych na uczeniu maszynowym </i>[wykład]</h2> \n",
|
||||
"<h3>Filip Graliński (2022)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Ciągła integracja i ewaluacja w projektach opartych na uczeniu maszynowym"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Dobre praktyki w tradycyjnej inżynierii oprogramowania\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Ciągła integracja\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Ciągła integracja (*continuous integration*, *CI*) to praktyka\n",
|
||||
"stosowana w tworzeniu oprogramowania polegają na częstym integrowaniu\n",
|
||||
"kodu opracowywanego przez programistów, zautomatyzowanym budowaniu\n",
|
||||
"oprogramowania i poddawaniu go testom.\n",
|
||||
"\n",
|
||||
"![img](./obrazy/ci.drawio.png \"Schemat procesu ciągłej integracji\")\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Ciągłe wdrażanie\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Ciągłe wdrażanie (*continuous deployment*, *CD*)\n",
|
||||
"automatyzuje również proces wdrażania oprogramowania. Oznacza to, że\n",
|
||||
"również procedura wdrażania musi zostać wyrażona jako kod\n",
|
||||
"przechowywany w systemie kontroli wersji.\n",
|
||||
"\n",
|
||||
"![img](./obrazy/cd.drawio.png \"Schemat procesu ciągłego wdrażania\")\n",
|
||||
"\n",
|
||||
"Ciągła integracja/ciągłe wdrożenie zazwyczaj współwystępuje z metodyką **DevOps**.\n",
|
||||
"\n",
|
||||
"CI/CD/DevOps w jednym zdaniu: robię to tak często, że to „nic takiego”.\n",
|
||||
"\n",
|
||||
"![img](./obrazy/seul-metro.png \"Przykład — budowa metra, źródło Wikipedia\")\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### CI/CD a uczenie maszynowe\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Dodanie do systemu modułów opartych na uczeniu maszynowym bardzo\n",
|
||||
"komplikuje proces CI/CD:\n",
|
||||
"\n",
|
||||
"- modele uczenia maszynowego (np. sieci neuronowe) powstają na bazie kodu źródłowego odpowiedzialnego za uczenie **i** danych uczących,\n",
|
||||
"- osobny kod jest odpowiedzialny za inferencję,\n",
|
||||
"- choć kod odpowiedzialny za uczenie i inferencję w miarę możliwości powinny podlegać standardowej metodologii testowania (np. testy jednostkowe), to ostatecznie testy systemów opartych na uczeniu maszynowym nie mają postaci zerojedynkowej\n",
|
||||
"- … raczej system może uzyskać lepszy albo gorszy wynik,\n",
|
||||
"- wdrożenie (a przynajmniej uczenie) wymaga często dużych zasobów obliczeniowych i specjalnego sprzętu (karty graficzne).\n",
|
||||
"\n",
|
||||
"Przy czym chcielibyśmy zachować „złote” zasady CI/CD.\n",
|
||||
"\n",
|
||||
"Wprowadzenie uczenia maszynowego do oprogramowania na tyle zmienia\n",
|
||||
"sytuację, że mówi się o **MLOps** zamiast DevOps.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Proces CI/CD rozszerzony o uczenie maszynowe\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"![img](./obrazy/mlops.drawio.png \"Schemat CI/CD rozszerzony o MLOps\")\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testowanie systemów opartych na uczeniu maszynowym\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Podobnie jak w wypadku tradycyjnego oprogramowania testowanie modeli\n",
|
||||
"uczenia maszynowego przyjmuje wiele form:\n",
|
||||
"\n",
|
||||
"- testy jednostkowe fragmentu kodu odpowiedzialnego za uczenie i inferencję,\n",
|
||||
"- testy uczenia i inferencji na spreparowanych danych\n",
|
||||
" - *corner cases*\n",
|
||||
" - uczenia „w kółko” na jednym przykładzie (czy funkcja kosztu spada do zera?)\n",
|
||||
"- testy inferencji na danych „śmieciowych” (czy system jest w stanie „przetrwać” wszystko?)\n",
|
||||
"- testy efektywności, przepustowości itp.\n",
|
||||
"- … lecz ostatecznie najistotniejsza jest odpowiedź na pytanie, jak dobry jest wynik na danych zbliżonych do rzeczywistych (**ewaluacja**)\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ewaluacja\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Rodzaje ewaluacji:\n",
|
||||
"\n",
|
||||
"- testy „na ludziach”,\n",
|
||||
" - testy A/B, analiza zachowania użytkownika\n",
|
||||
" - ewaluacja **manualna**, np. test MOS (*mean-opinion score*)\n",
|
||||
"- ewaluacja **automatyczna**\n",
|
||||
" - ewaluacja według wzoru\n",
|
||||
" - ewaluacja wyuczana przy użyciu uczenia maszynowego (!)\n",
|
||||
"\n",
|
||||
"Ostateczne kryterium ewaluacji: *money in the bank*, a właściwie\n",
|
||||
"*utility in the bank* (por. aksjomatyczna teoria użyteczności\n",
|
||||
"sformułowana przez Johna von Neumanna i Oskara Morgensterna).\n",
|
||||
"\n",
|
||||
"![img](./obrazy/utility.jpg \"Okładka książki „Theory of Games and Economic Behaviour”\")\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Psychologiczne pułapki oceniania\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"- efekt **pierwszeństwa** — *błędy pojawiające się na początku wypracowania oceniane są surowiej niż błędy na końcu wypracowania*\n",
|
||||
"\n",
|
||||
"- efekt **świeżości**\n",
|
||||
"\n",
|
||||
"- efekt „aureoli” — *mamy skłonność do przypisywania innych pozytywnych cech ludziom atrakcyjnym fizycznie*\n",
|
||||
"\n",
|
||||
"- wpływ **nastroju** na ocenianie — *w pochmurne dni ludzie gorzej oceniają stan gospodarki niż w słoneczne*\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Słabości „potocznej” matematyki\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Czy symptom świadczy o chorobie?\n",
|
||||
"\n",
|
||||
" | | | choroba | |\n",
|
||||
" | | | obecna | nieobecna |\n",
|
||||
" |---------+-----------+---------+---------------|\n",
|
||||
" | symptom | obecny | 37 | 33 |\n",
|
||||
" | | nieobecny | 17 | 13 |\n",
|
||||
"\n",
|
||||
"85% przepytanych pielęgniarek doszło do wniosku, że istnieje związek między symptomem a chorobą.\n",
|
||||
"\n",
|
||||
"**Korelacja** jest przez ludzi przeceniana, **regresja do średniej** — niedoceniania\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Jak uniknąć pułapek oceniania?\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"- stosować obiektywne miary,\n",
|
||||
"- najlepiej wymyślić syntetyczną funkcję oceny (pojedyncza liczba),\n",
|
||||
"- jeśli to możliwe, stosować automatyczną ewaluację.\n",
|
||||
"\n",
|
||||
"Konkretny sposób ewaluacji nazywamy **miarą** lub **metryką** ewaluacji.\n",
|
||||
"(Uwaga: nie ma nic wspólnego z terminami stosowanymi w matematyce!).\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Definicja metryki ewaluacji\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Ewaluację przeprowadzamy na ciągu danych wejściowych $(x)_i$ biorąc\n",
|
||||
"pod uwagę oczekiwane wyjście $(y)_i$ i rzeczywiste wyjście z systemu\n",
|
||||
"$(\\hat{y})_i$. Funkcja (metryka, miara) ewaluacji $\\mu$ powinna\n",
|
||||
"zwrócić skalarną wartość określającą jakość systemu, innymi słowy:\n",
|
||||
"\n",
|
||||
"$$\\mu \\colon X^{n} \\times Y^{n} \\times \\hat{Y}^{n} \\to \\mathcal{R},$$\n",
|
||||
"\n",
|
||||
"gdzie $X$ jest zbiorem możliwych wejść, $Y$ — zbiorem możliwych\n",
|
||||
"specyfikacji oczekiwanych wyjść, $\\hat{Y}$ — zbiorem możliwych wyjść\n",
|
||||
"(na ogół $Y = \\hat{Y}$, ale mogą być sytuacje, gdzie specyfikacja\n",
|
||||
"oczekiwanego wyjścia jest bardziej skomplikowana).\n",
|
||||
"\n",
|
||||
"Olbrzymia większość metryk ewaluacji nie bierze pod uwagę wejścia,\n",
|
||||
"lecz jedynie porównuje wyjście z systemu z oczekiwanym wyjściem, a zatem schemat upraszcza się do:\n",
|
||||
"\n",
|
||||
"$$\\mu \\colon Y^{n} \\times \\hat{Y}^{n} \\to \\mathcal{R}.$$\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Metryka ewaluacji — przykłady\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Jedną z najprostszych metryk ewaluacji jest **dokładność** (*accuracy*)\n",
|
||||
"jest to po prostu odsetek przypadków, gdy wyjście z systemu jest identyczne z oczekiwanym wyjściem.\n",
|
||||
"\n",
|
||||
"Narzędzie ewaluacyjne GEval ma zaimplementowane kilkadziesiąt (!) metryk ewaluacji\n",
|
||||
"\n",
|
||||
" -m,--metric METRIC Metric to be used, e.g.:RMSE, MSE, MAE, SMAPE,\n",
|
||||
" Pearson, Spearman, Accuracy, LogLoss, Likelihood,\n",
|
||||
" F1.0, F2.0, F0.25, Macro-F1.0, Macro-F2.0,\n",
|
||||
" Macro-F0.25, MultiLabel-F1.0, MultiLabel-F2.0,\n",
|
||||
" MultiLabel-F0.25, Mean/MultiLabel-F1.0,\n",
|
||||
" Probabilistic-MultiLabel-F1.0,\n",
|
||||
" Probabilistic-MultiLabel-F2.0,\n",
|
||||
" Probabilistic-MultiLabel-F0.25,\n",
|
||||
" MultiLabel-Likelihood, MAP, NDCG@3, BLEU, GLEU\n",
|
||||
" (\"Google GLEU\" not the grammar correction metric),\n",
|
||||
" WER, CER (Character-Error Rate), WAR, CAR\n",
|
||||
" (Character-Accuracy Rate (1-CER)), NMI, ClippEU,\n",
|
||||
" LogLossHashed, LikelihoodHashed, PerplexityHashed,\n",
|
||||
" BIO-F1, BIO-Weighted-F1, BIO-F1-Labels,\n",
|
||||
" TokenAccuracy, SegmentAccuracy, Soft-F1.0, Soft-F2.0,\n",
|
||||
" Soft-F0.25, Probabilistic-Soft-F1.0,\n",
|
||||
" Probabilistic-Soft-F2.0, Probabilistic-Soft-F0.25,\n",
|
||||
" Probabilistic-Soft2D-F1.0, Probabilistic-Soft2D-F2.0,\n",
|
||||
" Probabilistic-Soft2D-F0.25, Soft2D-F1.0, Soft2D-F2.0,\n",
|
||||
" Soft2D-F0.25, Haversine, CharMatch, Improvement@0.5,\n",
|
||||
" MacroAvg/Likelihood, MSE-Against-Interval,\n",
|
||||
" RMSE-Against-Interval, MAE-Against-Interval,\n",
|
||||
" BLEU:lm<\\s+|[a-z0-9]+> (BLEU on lowercased strings,\n",
|
||||
" only Latin characters and digits considered)\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Jakie własności ma dobra miara ewaluacji?\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"- spełnia zdroworozsądkowe aksjomaty\n",
|
||||
" - w szczególności dla przypadków brzegowych\n",
|
||||
" - jest stabilna\n",
|
||||
"\n",
|
||||
"- koreluje z ludzką oceną\n",
|
||||
" - a tak naprawdę z preferencjami użytkowników\n",
|
||||
"\n",
|
||||
"Ewaluacja ewaluacji! — czyli **metaewaluacja**\n",
|
||||
"\n",
|
||||
"![img](./obrazy/meta-eval.png \"Fragment artykułu o metaewaluacji\")\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Z powrotem do CI/CD\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Ewaluację można zatem traktować jako rozszerzenie procesu testowania oprogramowania.\n",
|
||||
"Ewaluacja nigdy nie powinna być jednorazowym procesem, powinna być wpleciona w proces CI/CD.\n",
|
||||
"Możemy więc mówić o **ciągłej ewaluacji**.\n",
|
||||
"\n",
|
||||
"Potrzeba ciągłego procesu, by upewnić się, że nasz system oparty na uczeniu maszynowym:\n",
|
||||
"\n",
|
||||
"- jest lepszy od prostego punktu odniesienia (*naive baseline*),\n",
|
||||
"- jest lepszy od rozwiązań konkurencji,\n",
|
||||
"- jest lepszy od systemu, który mieliśmy wczoraj, tydzień temu, rok temu…\n",
|
||||
"\n",
|
||||
"![img](./obrazy/mlops2.drawio.png \"Schemat MLOps rozszerzony o ciągłą ewaluację\")\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Dobór metryki ewaluacji — tłumaczenie maszynowe\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Jaka metryka jest najlepsza do oceny systemu tłumaczenia maszynowego?\n",
|
||||
"\n",
|
||||
"To zależy!\n",
|
||||
"\n",
|
||||
"**Scanariusz A**. Automatyczne tłumaczenie jest używane przez osoby\n",
|
||||
"nieznające języka docelowego w celu zrozumienia oryginalnego tekstu.\n",
|
||||
"\n",
|
||||
"**Scenariusz B**. Oczekujemy bardzo dobrej jakości tłumaczenia.\n",
|
||||
"Tłumaczenia maszynowe są poprawiane przez profesjonalnych tłumaczy,\n",
|
||||
"tłumaczenie maszynowe służy do przyspieszenia procesu.\n",
|
||||
"\n",
|
||||
"W scenariuszu A można zastosować standardowe metryki tłumaczenia\n",
|
||||
"maszynowego sprawdzające, na ile w tłumaczeniu zachowane elementy\n",
|
||||
"tłumaczenia referencyjnego, np. BLEU albo — lepiej — COMET, natomiast\n",
|
||||
"w scenariuszu B lepiej zastosować odległość edycyjną w celu\n",
|
||||
"oszacowania kosztu korekty.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Przykład systemu ewaluacji — GEval i Gonito\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"[GEval](https://gitlab.com/filipg/geval) to biblioteka w języku Haskell oraz narzędzie do ewaluacji uruchamiane z wiersza\n",
|
||||
"poleceń, zaś [Gonito](https://gitlab.com/filipg/gonito) to oparta na bibliotece GEval aplikacja webowa, platforma do ewaluacji wyzwań\n",
|
||||
"uczenia maszynowego.\n",
|
||||
"\n",
|
||||
"![img](./obrazy/gonito-platform.png \"Schemat platformy Gonito\")\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### System na produkcji, a my nie znamy oczekiwanych wartości!\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Estymacja jakości\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Uruchomiliśmy nasz system w wersji produkcyjnej, skąd wiemy, że system\n",
|
||||
"zachowuje się poprawnie?\n",
|
||||
"\n",
|
||||
"Można anotować lub poprawiać manualnie próbki danych produkcyjnych,\n",
|
||||
"rozszerzać w ten sposób zbiory testowe i dokonywać na nich ewaluacji.\n",
|
||||
"\n",
|
||||
"Można też stosować metody **estymacji jakości** (*quality estimation*),\n",
|
||||
"tzn. przewidywać jakość wyłącznie na podstawie wyjścia (bez znajomości\n",
|
||||
"oczekiwanego wyjścia). Na przykład w systemie tłumaczenia maszynowego\n",
|
||||
"można w tym celu stosować model języka docelowego.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadania proponowane na laboratoria\n",
|
||||
"\n",
|
||||
"### Zadanie 1.\n",
|
||||
"\n",
|
||||
"Skonfigurujcie minimalne zadanie uczenia maszynowego na dowolnym serwerze ciągłej integracji (Jenkins, GitLabCI, GitHub Actions itp.). Zadanie powinno obejmować wyuczenie prostego modelu i ewaluację.\n",
|
||||
"\n",
|
||||
"### Zadanie 2.\n",
|
||||
"\n",
|
||||
"Dokonajcie konwersji wybranego zbioru danych do standardu wyzwania [Gonito](https://gitlab.com/filipg/gonito). Zob. [szczegółowe instrukcje odnośnie do tworzenia wyzwania](https://gitlab.com/filipg/geval#preparing-a-gonito-challenge).\n",
|
||||
"\n",
|
||||
"### Zadanie 3.\n",
|
||||
"\n",
|
||||
"Dopiszcie nowe przypadki testowe dla wybranej metryki ewaluacji w programie [GEval](https://gitlab.com/filipg/geval). Zob. [przykład testów dla nowej metryki](https://gitlab.com/filipg/geval/-/commit/819fbecedc6f744a1a08f21c11067191837f87a2) (od pliku `test/Spec.hs`).\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"org": null
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 1
|
||||
}
|
||||
681
06_pmbok.ipynb
Normal file
681
06_pmbok.ipynb
Normal file
@ -0,0 +1,681 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "raw",
|
||||
"metadata": {},
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 6. <i>Zarządzania projektem informatycznym w metodyce PMBOK </i>[wykład]</h2> \n",
|
||||
"<h3>Jacek Marciniak (2022)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1. Dlaczego konieczne jest zarządzanie projektem informatycznym?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Czy tworzenie oprogramowania jest proste?\n",
|
||||
"\n",
|
||||
"Zjawisko zwane \"Kryzysem oprogramowania\":\n",
|
||||
"- Początki informatyki to era tworzenia małych programów przez ich bezpośrednich odbiorców.\n",
|
||||
"- Rozwój informatyki w połowie lat sześćdziesiątych doprowadził do tworzenia znacznie bardziej złożonych systemów przez profesjonalną grupę zawodową – programistów.\n",
|
||||
"- Podjęte zostały próby tworzenia złożonych systemów informatycznych, których tworzeniem zajmowały się duże zespoły programistyczne. \n",
|
||||
"- Wiele z tych projektów nie zostało nigdy ukończonych, inne znaczenie przekroczyły założony czas i budżet oraz były niezadowalającej jakości.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Kryzys oprogramowania w rozkwicie – lata 90-te XX wieku\n",
|
||||
"\n",
|
||||
"Zjawisko kryzysku oprogramowania zostało zauważone jako negatywnie wpływające na rynek produkcji oprogramowania w latach 90-tych XX wieku:\n",
|
||||
"- W latach dziewięćdziesiątych 90% znaczących firm programistycznych w USA przyznawało się do opóźnień w tworzeniu oprogramowania.\n",
|
||||
"- Przyjęło się, że w systemach informatycznych błędy w oprogramowaniu stają się dominujące nad błędami sprzętowymi.\n",
|
||||
"- Niepowodzeniem kończy się 31% projektów informatycznych, a dalsze 53% projektów wymaga zwiększenia czasu, budżetu, bądź ograniczenia założonych funkcjonalności lub jakości. Jedynie 16% projektów kończy się na czas!\n",
|
||||
"- Wg. danych z 1995 roku połowa ukończonych projektów informatycznych posiadało w chwili ukończenia mniej niż 42% pierwotnie założonych funkcjonalności.\n",
|
||||
"- W 1995 roku projekty skasowane w USA kosztowały 81 mld USD.\n",
|
||||
"\n",
|
||||
"Niestety,ale prawie 30 lat później powyższe problemy nadal występują!\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Przyczyny kryzysu oprogramowania\n",
|
||||
"\n",
|
||||
"Przyczyny wynikające z charakteru projektów informatycznych:\n",
|
||||
"- Duża złożoność systemów informatycznych\n",
|
||||
"- Niepowtarzalność poszczególnych przedsięwzięć informatycznych\n",
|
||||
"- Nowe technologie wykorzystywane do tworzenia oprogramowanie rozpowszechniają się bardzo szybko. Często docierają w stanie niedojrzałym powodując frustrację twórców oprogramowania\n",
|
||||
"- Presja wymuszająca bardzo szybką dostawę gotowych systemów. Projekty 4-8 letnie są nieakceptowalne!\n",
|
||||
"- Poziom świadomości współczesnych użytkowników powodują wzrost wymagań odnośnie złożoności programów\n",
|
||||
"- Obecne systemy to w wielu wypadkach integracja wielu komponentów pochodzących od różnych producentów\n",
|
||||
"- Długi i kosztowny cykl tworzenia oprogramowania, wysokie prawdopodobieństwo niepowodzenia projektu programistycznego.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Przyczyny wynikające ze złego prowadzenia projektów:\n",
|
||||
"\n",
|
||||
"- Specyfikacje są niekompletne i niejednoznaczne.\n",
|
||||
"- Za mało planowania.\n",
|
||||
"- Zła komunikacja.\n",
|
||||
"- Złe oszacowania.\n",
|
||||
"- Brak jasno określonych zakresów odpowiedzialności.\n",
|
||||
"- Mało uwagi poświęconej problemom jakości.\n",
|
||||
"- Za mało udziału użytkowników końcowych.\n",
|
||||
"- Nieświadomi zagrożeń kierownicy projektów.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Metody walki z kryzysem oprogramowania\n",
|
||||
"\n",
|
||||
"Kryzys oprogramowania można minimalizować poprzez:\n",
|
||||
"- Korzystanie z metod inżynierii oprogramowania,\n",
|
||||
"- Korzystanie z metodyk zarządzania projektami.\n",
|
||||
"\n",
|
||||
"Inżynieria oprogramowania jest wiedzą techniczną dotycząca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu – oprogramowania. Inżynieria oprogramowania zapewnia:\n",
|
||||
"- Techniki i narzędzi ułatwiające pracę nad złożonymi systemami,\n",
|
||||
"- Metody wspomagające analizę nieznanych problemów oraz ułatwiające wykorzystanie wcześniejszych doświadczeń,\n",
|
||||
"- Usystematyzowanie procesu wytwarzania oprogramowania, tak aby ułatwić jego planowanie i monitorowanie.\n",
|
||||
"\n",
|
||||
"Metodyki zarządzania projektami określają zasady na jakich należy skutecznie prowadzić projekt informatyczny.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2. Czym jest projekt i zarządzanie projektem informatycznym\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Czym jest projekt informatyczny\n",
|
||||
"\n",
|
||||
"Projekt to sekwencja unikatowych, złożonych i powiązanych ze sobą aktywności, które mają doprowadzić do określonego celu i muszą zostać zrealizowane w określonym okresie czasu, w założonym budżecie oraz zgodnie z określoną specyfikacją.\n",
|
||||
"\n",
|
||||
"Gdzie:\n",
|
||||
"\n",
|
||||
"1) Sekwencja aktywności:\n",
|
||||
"- Jako aktywność rozumie się określony zestaw zadań do wykonania,\n",
|
||||
"- Aktywności powinny być realizowane w sposób uporządkowany – w sekwencji,\n",
|
||||
"- Sekwencja wykonywania zadań powinna wynikać ze specyfikacji technicznej, a nie z uwarunkowań zarządczych,\n",
|
||||
"- Przy określaniu sekwencji aktywności należy określić : a) Co jest potrzebne jako wejście do danej aktywności aby rozpocząć jej realizację, b) jakie aktywności wygenerują jako produkt to wejście.\n",
|
||||
"\n",
|
||||
"2) Aktywności są unikatowe:\n",
|
||||
"- Każda z aktywności jest niepowtarzalna tzn. nie zdarzyła się nigdy wcześniej, ani nie zdarzy się nigdy później,\n",
|
||||
"- Na podobne (potencjalnie powtarzalne) aktywności wpływa zawsze tyle czynników zewnętrznych (np. opóźniła się realizacja innego fragmentu systemu, rozchorował się kluczowy członek zespołu, uszkodzeniu uległ sprzęt), że aktywności takie nigdy nie będą powtarzalne.\n",
|
||||
"\n",
|
||||
"3) Aktywności są złożone – każda z czynności wykonywanych przez zespoły programistyczne to czynność złożona (np. zaprojektowanie architektury bazy danych, zaprojektowanie interfejsu użytkownika).\n",
|
||||
"\n",
|
||||
"4) Aktywności są powiązane:\n",
|
||||
"- Istnieje logiczny i techniczny związek pomiędzy poszczególnymi parami aktywności,\n",
|
||||
"- Istnieje określona ścieżka realizacji aktywności, która doprowadzi do ukończenia projektu,\n",
|
||||
"- Wyjście jednej aktywności jest zawsze wejściem do kolejnej.\n",
|
||||
"\n",
|
||||
"5) Projekt prowadzi do określonego celu:\n",
|
||||
"- Każdy projekt ma tylko jeden cel,\n",
|
||||
"- Duże projekty mogą być podzielone na podprojekty z różnymi celami, jednak każdy z podprojektów jest również projektem,\n",
|
||||
"- Podział na podprojekty ułatwia zarządzanie całym projektem.\n",
|
||||
"\n",
|
||||
"6) Projekt musi zostać zrealizowany w określonym czasie:\n",
|
||||
"- Termin narzucony jest przez zarząd projektu, bądź zewnętrznie przez klienta,\n",
|
||||
"- Projekt jest **zakończony** w określonym terminie niezależnie od tego czy prace zostały zakończone czy nie!\n",
|
||||
"\n",
|
||||
"7) Projekt musi być wykonany w ramach założonego budżetu:\n",
|
||||
"- Każdy projekt posiada określony zasoby dedykowane do realizacji projektu: ludzie, pieniądze, urządzenia,\n",
|
||||
"- Zasoby są przez kierownika projektu traktowane jako zasoby trwałe (tzn. dostępne wtedy kiedy są potrzebne), chociaż przez zarząd firmy mogą być traktowane jako zasoby rotacyjne (tzn. przesuwane pomiędzy różnymi projektami).\n",
|
||||
"\n",
|
||||
"8) Projekt musi być wykonany zgodnie ze specyfikacją:\n",
|
||||
"- Odbiorca projektu oczekuje, że będzie on spełniał pewne wymagania funkcjonalne zapisane w specyfikacji,\n",
|
||||
"- Kierownik projektu przyjmuje że specyfikacja jest niezmienna w określonym przyroście,\n",
|
||||
"- Zmienność specyfikacji jest stałym elementem każdego projektu oraz wyzwaniem dla każdego kierownika projektu.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Interesariusze projektu\n",
|
||||
"\n",
|
||||
"Interesariusze (ang. stakeholders) to osoby, bądź organizacje, które są zainteresowane wynikami projektu. Osoby te są:\n",
|
||||
"- Aktywnie zaangażowane w realizację projektu, bądź\n",
|
||||
"- Mają coś do zyskania, bądź stracenia gdy wynik projektu zostanie osiągnięty.\n",
|
||||
"\n",
|
||||
"Kluczowi interesariusze mogą doprowadzić do sukcesu, bądź porażki projektu niezależnie od tego czy wszystkie cele projektu zostały osiągnięte bądź nie.\n",
|
||||
"\n",
|
||||
"Jeżeli kluczowi interesariusze projektu nie są zadowoleni **NIKT** nie jest zadowolony.\n",
|
||||
"\n",
|
||||
"Konieczne jest zidentyfikowanie wszystkich interesariuszy przed rozpoczęciem projektu – nie rozpoznanie na czas potrzeb kluczowego interesariusza może doprowadzić do porażki projektu!\n",
|
||||
"\n",
|
||||
"Podstawowi interesariusze projektu:\n",
|
||||
"- Sponsor projektu – osoba, bądź instytucja finansująca projekt.\n",
|
||||
"- Klient – odbiorca produktów projektu,\n",
|
||||
"- Kierownik projektu – osoba odpowiedzialna za prowadzenie projektu,\n",
|
||||
"- Zespół projektowy – osoby realizujące projekt,\n",
|
||||
"- Dostawcy – osoby, bądź instytucje współpracujące przy projekcie,\n",
|
||||
"- Biuro projektowe – osoby wspierające organizacyjnie projekt,\n",
|
||||
"- Kadra zarządzająca instytucji klienta – osoby pośrednio zainteresowane produktami projektu.\n",
|
||||
"\n",
|
||||
"Interesariusze bardzo często mają sprzeczne interesy. Kierownik projektu każdorazowo odpowiedzialny jest za identyfikowanie i rozwiązywanie konfliktu interesów.\n",
|
||||
"\n",
|
||||
"W przypadku wątpliwości co do sprzecznych interesów decyzje powinny być zawsze podejmowane na korzyść **klienta**!\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Parametry projektu\n",
|
||||
"\n",
|
||||
"Dla każdego projektu można wyróżnić 5 składowych:\n",
|
||||
"- Zakres,\n",
|
||||
"- Jakość,\n",
|
||||
"- Koszt,\n",
|
||||
"- Czas,\n",
|
||||
"- Zasoby.\n",
|
||||
"\n",
|
||||
"Składowe te pozostają między sobą w zależności – zmiana w jednej składowej pociąga zawsze zmianę w innej składowej. Aby projekt zakończył się sukcesem wszystkie te składowe muszą pozostawać zrównoważone!\n",
|
||||
"\n",
|
||||
"1) Zakres projektu:\n",
|
||||
"- Zakres projektu określa ramy w których realizowany jest projekt; określa co ma być zrobione, ale również to co ma nie być zrobione,\n",
|
||||
"- W systemach informatycznych zakres zapisywany jest w postaci wymagań funkcjonalnych, bądź każdy inny dokument określający czego dotyczy projekt (dokumentacja rozpoczęcia projektu, formularz projektowy),\n",
|
||||
"- Dokument określający zakres projektu jest podstawą wszystkich prac prowadzonych w projekcie. Krytyczne jest, aby zakres projektu określony został w sposób poprawny. \n",
|
||||
"- Zakres projektu będzie się zmieniał: nie jesteśmy w stanie określić kiedy i w jakim stopniu, ale pewne jest że w każdym projekcie zmiany te się pojawią. Ważne jest więc szybkie wykrycie tych zmian oraz wdrożenie ich do realizacji. \n",
|
||||
"\n",
|
||||
"2) Jakość:\n",
|
||||
"\n",
|
||||
"Dwa rodzaje jakości należy uwzględniać w każdym projekcie:\n",
|
||||
"- Jakość produktu – dotyczy jakości produktu końcowego projektu\n",
|
||||
"- Jakość procesu – dotyczy procesu prowadzenia projektu. Zagadnienie dotyczy tego w jaki sposób przebiega projekt, czy proces ten wymaga usprawnień i modyfikacji.\n",
|
||||
"\n",
|
||||
"W każdym projekcie wskazane jest, aby uruchomić procedury utrzymania jakości. Podejście takie zapewnia:\n",
|
||||
"- Zwiększenie satysfakcji klienta projektu,\n",
|
||||
"- Zwiększenie efektywnego wykorzystania zasobów oraz zmniejszenie kosztów.\n",
|
||||
"\n",
|
||||
"3) Koszt:\n",
|
||||
"- Koszt projektu jest najpoważniejszą składową każdego projektu. \n",
|
||||
"- Realizacja projektu dokonuje się zawsze w ramach przypisanego budżetu, niezależnie od tego czy projekt jest realizowany na potrzeby zewnętrzne (tzn. dla klienta zewnętrznego), czy też w ramach danej organizacji.\n",
|
||||
"- Bardzo często przy rozpoczynaniu projektu klient jest skłonny przeznaczyć na ten projekt określoną kwotę. Ważne jest, aby rozpoznać taką sytuację i w sytuacji w której jest za niska względem realnych spodziewanych kosztów wykonać tylko określoną część zadań projektowych.\n",
|
||||
"- Poprawne oszacowanie kosztu projektu jest krytyczne w sytuacjach sformalizowanych umowami. Błędy w szacunku mogą uniemożliwić realizację projektu.\n",
|
||||
"\n",
|
||||
"4) Czas:\n",
|
||||
"- Dla każdego projektu określany jest termin w którym projekt powinien się zakończyć. \n",
|
||||
"- W wielu sytuacjach koszt i czas są odwrotnie powiązane ze sobą: jeżeli chcemy skrócić czas realizacji projektu, wzrośnie nam jego koszt.\n",
|
||||
"- Czas postrzegany jako zasób posiada bardzo ciekawą charakterystykę: niezależnie od tego czy jest używany jest zawsze konsumowany! Celem kierownika projektu jest więc jak najbardziej efektywne wykorzystanie czasu. \n",
|
||||
"- Czas „przyszły” może być traktowany jako zasób zbywalny tzn. może stać się przedmiotem handlu w ramach projektu, bądź pomiędzy projektami.\n",
|
||||
"\n",
|
||||
"5) Zasoby:\n",
|
||||
"- Zasoby to byty takie jak ludzie, wyposażenie, powierzchnie biurowe, sprzęt. Zasoby traktujemy jako dobra zbywalne o ograniczonej dostępności, które podlegają harmonogramowaniu, mogą być zbywane, bądź nabywane. \n",
|
||||
"- Niektóre zasoby są dostępne zawsze, inne dostępne są tylko w określonym okresie czasu. Niezależnie od tego zasoby są kluczowym elementem harmonogramowania aktywności projektu.\n",
|
||||
"- W projektach informatycznych podstawowym zasobem są ludzie oraz dostępność czasu procesorów (np. do testowania systemu).\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Trójkąt zakresu\n",
|
||||
"\n",
|
||||
"Zależności pomiędzy parametrami projektu obrazujące konieczność zachowania równowagi pomiędzy nimi obrazuje następujący Trójkąt zakresu:\n",
|
||||
"\n",
|
||||
"![img](./obrazy/trojkat_zakresu.png \"Trójkąt zakresu\")\n",
|
||||
"\n",
|
||||
"W podejściu tym plan projektu zakłada określony czas, koszty i zasoby na zrealizowanie projektu o wyspecyfikowanym zakresie i określonej jakości. Projekt jest zrównoważonym bytem uwzględniającym wszystkie pięć wymienionych składowych. Równowaga ta nie będzie nigdy trwała zbyt długo!!!\n",
|
||||
"\n",
|
||||
"Trójkąt zakresu projektu obrazuje jak w trakcie realizacji projektu zmiany jednej ze składowych wpływają na inne składowe, np..:\n",
|
||||
"- Zwiększenie zakresu (np. na życzenie klienta) wymagało będzie zwiększenia dostępności zasobów i zwiększenia kosztów, bądź czasu,\n",
|
||||
"- Skrócenie terminu (np. w odpowiedzi na żądanie klienta) wymagało będzie zmniejszenia zakresu, bądź jakości lub też zwiększenia kosztu i dostępności zasobów,\n",
|
||||
"- Zmiana dostępności zasobów (np. opuszczenie projektu przez kluczowego programistę) uniemożliwi osiągnięcie zaplanowanego zakresu, itd.\n",
|
||||
"\n",
|
||||
"Kto kontroluje poszczególne składowe trójkąta:\n",
|
||||
"- Kierownik projektu: użycie zasobów, czas realizacji projektu,\n",
|
||||
"- Zarząd projektu: koszt oraz użycie zasobów\n",
|
||||
"- Klient: zakres, jakość i termin zakończenia projektu.\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zarządzanie projektem\n",
|
||||
"\n",
|
||||
"Zarządzanie projektem to zestaw narzędzi i technik wykonywanych przez ludzi, aby opisywać, organizować oraz monitorować pracę aktywności składających się na projekt.\n",
|
||||
"\n",
|
||||
"Kierownicy projektu to osoby odpowiedzialne za zarządzanie procesami realizowanymi w ramach projektu, stosujące narzędzia i techniki, aby zrealizować cele projektu.\n",
|
||||
"\n",
|
||||
"Zarządzanie projektem to proces który:\n",
|
||||
"- Zakłada planowanie, realizowanie planów oraz kontrolowanie przyrostu i efektywności prowadzonych prac,\n",
|
||||
"- Obejmuje identyfikowanie wymagań, określanie celów projektu oraz równoważenie składowych projektu,\n",
|
||||
"- Obejmuje czynności mające na celu rozpoznanie celów interesariuszy\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Kierownik projektu (ang. Project Manager; PM)\n",
|
||||
"\n",
|
||||
"Kierownik projektu to osoba, która powinna posiadać różne kompetencje niezbędne do prawidłowego prowadzenia projektu informatycznego. Bardzo często kierownikami projektu zostają osoby o wykształceniu technicznym, jednak wiadomości techniczne nie są krytyczne w pracy kierownika projektu.\n",
|
||||
"\n",
|
||||
"Podstawowe kompetencje kierownika projektu:\n",
|
||||
"- Zdolności komunikacji,\n",
|
||||
"- Zdolności organizacyjne i planistyczne,\n",
|
||||
"- Zdolności budżetowania,\n",
|
||||
"- Zdolności rozwiązania konfliktów,\n",
|
||||
"- Zdolności negocjacji i wpływania na innych,\n",
|
||||
"- Zdolności przywódcze,\n",
|
||||
"- Zdolności budowania zespołu i zdolności motywacji.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3. Metodyka PMBOK: cykl życia projektu, a procesy zarządzania projektem\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zarządzanie projektem w podejściu tradycyjnym\n",
|
||||
"\n",
|
||||
"Zarządzanie projektami w podejściu tradycyjnym bazuje na filozofii prowadzenia projektu w oparciu gotowy zestaw rozwiązań uruchamianych w określonym momencie realizacji projektu. Podejść do realizacji projektów w podejściu tradycyjnym jest wiele, różnią się one między sobą w mniejszym lub większym zakresie.\n",
|
||||
"\n",
|
||||
"Obecnie jedną z najbardziej rozpowszechnionych metodyk tradycyjnego zarządzania projektem, w tym zarządzania projektem informatycznym, jest metodyka **Project Management Body of Knowledge (PMBOK)** opracowana przez **Project Management Institute (PMI)**."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Fazy projektu i cykl życia projektu\n",
|
||||
"\n",
|
||||
"We wszystkich projektach można wyróżnić pewne fazy ich realizacji. W najprostszym podejściu wyróżniamy takie fazy jak: rozpoczęcie, realizacja, zakończenie. Ilość faz zależy od złożoności projektu oraz dziedziny przemysłu w której jest realizowany (budownictwo, produkcja maszyn, projekty informatyczne).\n",
|
||||
"\n",
|
||||
"Cyklem życia projektu nazywamy wszystkie fazy projektu występujące podczas jego realizacji.\n",
|
||||
"Fazy projektu i cykl życia projektu odnoszą się do pracy, która jest realizowana w projekcie w celu osiągnięcia celów projektu. W projektach informatycznych **fazy projektu** są opisywane **cyklem życia oprogramowania**. Przykładami takiego cyklu może być model kaskadowy, Unified Process, bądź SCRUM. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Procesy zarządzania projektem\n",
|
||||
"\n",
|
||||
"Zarządzanie projektem to zestaw czynności polegających na planowaniu, szacowaniu i kontrolowaniu pracy zespołów ludzkich w celu osiągnięcia oczekiwanego celu w zadanym okresie czasu, przy zachowaniu określonego budżetu, w oparciu o określoną specyfikację.\n",
|
||||
"\n",
|
||||
"Zarządzanie projektem jest realizowane poprzez tzw. procesy zarządzania projektem (ang. project management processes). Procesy są wykonane przez ludzi i podobnie jak fazy projektu są powiązane pomiędzy sobą. W modelu tradycyjnym wyróżnia się następujące **grupy procesów zarządzania projektem** (inaczej **fazy zarządzania projektem**):\n",
|
||||
"- Rozpoczęcie,\n",
|
||||
"- Planowanie,\n",
|
||||
"- Wykonywanie,\n",
|
||||
"- Monitorowanie i kontrola,\n",
|
||||
"- Zamykanie.\n",
|
||||
"\n",
|
||||
"Fazy projektu i cykl życia projektu to nie to samo co procesy zarządzania projektem:\n",
|
||||
"- **Fazy projektu i cykl życia projektu** dotyczą czynności które muszą być wykonane aby osiągnąć cel projektu (czynności są realizowane przez zespoły wykonawcze zaangażowane w realizację projektu),\n",
|
||||
"- **Procesy zarządzania projektem** dotyczą aktywności prowadzonych podczas zarządzania projektem (czynności są realizowane przez osoby zarządzające projektem – przeważnie kierownika projektu). \n",
|
||||
"\n",
|
||||
"Każdy z projektów musi przejść przez fazę Zamykania. Dotyczy to również tych projektów, które zostały przerwane.\n",
|
||||
"\n",
|
||||
"1) Fazy zarządzania projektem: **Rozpoczęcie**\n",
|
||||
"\n",
|
||||
"W ramach fazy Rozpoczęcia definiowane są prace, które muszą być zrealizowane w ramach projektu oraz określane są zakresy odpowiedzialności w projekcie. Faza Rozpoczęcia ma doprowadzić do określenia zakresu projektu. Aby tego dokonać należy zrealizować następujące prace:\n",
|
||||
"- Wyspecyfikować problemy które zostaną rozwiązane / bądź korzyści które zostaną osiągnięte po zrealizowaniu projektu,\n",
|
||||
"- Określić cel projektu,\n",
|
||||
"- Określić warunki, które muszą zajść aby osiągnąć cel projektu,\n",
|
||||
"- Określić kryteria oceny tego czy projekt zakończył się sukcesem,\n",
|
||||
"- Wyspecyfikować warunki, zagrożenia, bądź przeszkody które mogą wpłynąć na sukces końcowy projektu.\n",
|
||||
"\n",
|
||||
"Zakres projektu jest zapisywany w dokumencie projektowym fazy rozpoczęcia na podstawie którego podjęte będą decyzje o rozpoczęciu projektu. Dokument projektowy tworzony jako produkt fazy Rozpoczęcia występuje w różnych postaciach: \n",
|
||||
"- Karta projektu, \n",
|
||||
"- Specyfikacja projektu, \n",
|
||||
"- Specyfikacja zakresu, \n",
|
||||
"- Początkowa definicja projektu, \n",
|
||||
"- Specyfikacja zakresu pracy, Protokół uzgodnień. \n",
|
||||
"\n",
|
||||
"Dokument taki jest często uzupełniany wymagane przez klienta do rozpoczęcia prac przy projekcie:\n",
|
||||
"- Analiza ryzyka,\n",
|
||||
"- Analiza korzyści,\n",
|
||||
"- Zwrot z inwestycji.\n",
|
||||
"\n",
|
||||
"2) Fazy zarządzania projektem: **Planowanie**\n",
|
||||
"\n",
|
||||
"Planowanie przez wielu członków zespołu projektowego jest traktowane jako niepotrzebna strata czasu ponieważ jest elementem ciągle się zmieniającym, nigdy nie aktualnym. Plany są jednak niezbędne aby w lepszy sposób rozpocząć i prowadzić projekt. \n",
|
||||
"Plany powinny być postrzegane jako byty dynamiczne tzn. takie które podlegają zmianom. Kierownik projektu powinien spodziewać się, że plany mogą ulec zmianie. Plany zapewniają nam:\n",
|
||||
"- Zmniejszenie niepewności co do przebiegu projektu,\n",
|
||||
"- Zwiększenie rozumienia celów projektu,\n",
|
||||
"- Zwiększenie efektywności prowadzenia projektu. \n",
|
||||
"\n",
|
||||
"Wynikiem fazy planowania jest:\n",
|
||||
"- Szczegółowy opis aktywności do wykonania,\n",
|
||||
"- Zasoby niezbędne do zrealizowania tych aktywności,\n",
|
||||
"- Harmonogram realizacji projektu,\n",
|
||||
"- Szacowany koszt i data zakończenia projektu.\n",
|
||||
"\n",
|
||||
"Poszczególne składowe projektu mogą ulegać zmianie. Podczas tworzenia planów należy przewidywać możliwe zmiany składowych planu, np.:\n",
|
||||
"- Jeżeli aktywność projektu zakończy się wcześniej lub później niż zaplanowano w jaki sposób rozdysponować zasoby?\n",
|
||||
"- Jeżeli jedna aktywność zakończy się z dużym opóźnieniem, czy istnieje możliwość takiego relokowania zasobów, aby zminimalizować wpływ tego opóźnienia na cały projekt?\n",
|
||||
"- W jaki sposób skracać czasy realizacji, aby unikać konfliktów wykorzystania kluczowych zasobów?\n",
|
||||
"- W jaki sposób zasoby mogą być relokowane pomiędzy projektami, aby unikać opóźnień w poszczególnych projektach?\n",
|
||||
"\n",
|
||||
"3) Fazy zarządzania projektem: **Wykonywanie**\n",
|
||||
"\n",
|
||||
"Faza Wykonywania dotyczy upoważnienia zespołu projektowego do realizacji zadań zapisanych w planie projektu. Wykonywanie planu obejmuje następujące aktywności:\n",
|
||||
"- Określenie zasobów, które muszą być dostępne aby zrealizować określoną aktywność projektu,\n",
|
||||
"- Przypisanie wykonawców do danej aktywności,\n",
|
||||
"- Określenie harmonogramu realizacji określonej aktywności,\n",
|
||||
"- Uruchomienie realizacji planu.\n",
|
||||
"\n",
|
||||
"Ważnym elementem fazy wykonywania jest określenie zespołu który będzie odpowiedzialny za realizację poszczególnych aktywności projektu. Kluczowi członkowie zespołu są określani w fazie Planowania, w fazie Wykonywania są identyfikowani pozostali członkowie zespołu. W dużych instytucjach zespoły wykonawcze są alokowane w miarę potrzeb wynikających z przebiegu projektu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"4) Faza zarządzania projektem: **Monitorowanie i kontrola**\n",
|
||||
"\n",
|
||||
"Podstawowym założeniem każdego projektu jest to, że niezależnie od zaangażowania i kompetencji zespołów wykonawczych przyjęty plan nie będzie realizowany! **Opóźnienia są nierozerwalną składową każdego projektu!** Kierownik projektu musi mieć więc wypracowany system, który pozwoli mu na monitorowanie przebiegu projektu. System monitoringu powinien pokazywać mu prace wykonane w stosunku do prac zaplanowanych. \n",
|
||||
"\n",
|
||||
"Monitorowania i kontrola obejmuje:\n",
|
||||
"- Określenie systemu raportowego pokazującego przyrosty w projekcie,\n",
|
||||
"- Określenie procesu rozwiązywania problemów,\n",
|
||||
"- Monitorowanie przyrostu projektu względem planu,\n",
|
||||
"- Zmian w planach projektu.\n",
|
||||
"\n",
|
||||
"5) Faza zarządzania projektem: **Zamykanie**\n",
|
||||
"\n",
|
||||
"Faza zamykania projektu pozwala na określenie, że projekt się zakończył oraz (w sytuacji sukcesu) dostarczenie wyników projektu klientowi. W trakcie fazy zamykania oceniany jest przebieg projektu w celu usprawnienia procesu w przyszłych projektach. Ocenia się następujące elementy projektu:\n",
|
||||
"- Czy produkty projektu spełniają oczekiwania klienta?\n",
|
||||
"- Czy produkty projektu spełniają oczekiwania kierownika projektu?\n",
|
||||
"- Czy zespół zakończył projekt zgodnie z założonym planem?\n",
|
||||
"- Czy przyjęta metodologia prowadzenia projektu sprawdziła się?\n",
|
||||
"- Czego dana organizacja może się nauczyć z zakończonego projektu?\n",
|
||||
"\n",
|
||||
"Faza ta jest często pomijana. Uniemożliwia to wyciągnięcie wniosków z projektu oraz usprawnienie procesów realizacji przyszłych projektów.\n",
|
||||
"\n",
|
||||
"Aktywności realizowane w trakcie zamykania projektu:\n",
|
||||
"- Uzyskanie akceptacji klienta,\n",
|
||||
"- Zainstalowanie produktów projektu,\n",
|
||||
"- Ukończenie dokumentacji projektowej,\n",
|
||||
"- Uzyskanie audytu po-wdrożeniowego,\n",
|
||||
"- Napisanie raportu zamknięcia projektu,\n",
|
||||
"- Świętowanie zakończenia projektu!\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Iteracyjność w procesie zarządzania projektem\n",
|
||||
"\n",
|
||||
"Realizacja projektu jest procesem iteracyjnym: po zakończeniu jednej z faz kierownik projektu oraz interesariusze projektu mogą modyfikować założenia projektu co może mieć wpływ na dalszy procesu zarządzania projektem. Możliwe scenariusze zarządzania projektem:\n",
|
||||
"\n",
|
||||
"![img](./obrazy/iteracyjnosc.png \"Iteracyjność w procesie zarządzania projektem\")"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4. Metodyka PMBOK: Obszary wiedzy w zarządzaniu projektem\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Obszary wiedzy dotyczące zarządzania projektem (ang. Project management knowledge areas) to pojęcie metodyki PMBOK, które są innym sposobem grupowania procesów zarządzania projektem. Poszczególne obszary wiedzy posiadają cechy wspólne i w oparciu o te cechy wspólne realizowane jest grupowanie. Procesy zarządzania projektem oddają porządek w jakim wykonywane są czynności realizowane w ramach prowadzenia projektu.\n",
|
||||
"\n",
|
||||
"Wyróżnione obszary wiedzy w zarządzaniu projektem:\n",
|
||||
"- Zintegrowane zarządzanie projektem,\n",
|
||||
"- Zarządzanie zakresem,\n",
|
||||
"- Zarządzanie czasem,\n",
|
||||
"- Zarządzanie kosztem,\n",
|
||||
"- Zarządzanie jakością,\n",
|
||||
"- Zarządzanie zasobami ludzkimi,\n",
|
||||
"- Zarządzanie komunikacją,\n",
|
||||
"- Zarządzanie ryzykiem,\n",
|
||||
"- Zarządzanie procesami zaopatrzenia.\n",
|
||||
"\n",
|
||||
"1) **Zintegrowane zarządzanie zakresem**\n",
|
||||
"\n",
|
||||
"Zintegrowane zarządzanie projektem dotyczy koordynowania wszystkich aspektów projektu. Obejmuje następujące procesy:\n",
|
||||
"- Budowę wstępnego zakresu projektu,\n",
|
||||
"- Budowę planu zarządzania projektem,\n",
|
||||
"- Kierowanie wykonaniem projektu\n",
|
||||
"- Monitorowanie i kontrolowanie realizacji zadań w projekcie,\n",
|
||||
"- Zintegrowana kontrola zmian w projekcie,\n",
|
||||
"- Zamykanie projektu\n",
|
||||
"\n",
|
||||
"Poszczególne procesy przynależą do różnych faz zarządzania projektem.\n",
|
||||
"\n",
|
||||
"Wykorzystywane narzędzia:\n",
|
||||
"- Metodyka Earned Value Management (EVM),\n",
|
||||
"- Oprogramowanie wspierające prowadzenie projektu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"2) **Zarządzanie zakresem**\n",
|
||||
"\n",
|
||||
"Zarządzanie zakresem projektu obejmuje zarządzanie zakresem pracy który jest niezbędny do wykonania w projekcie. Obejmuje następujące procesy:\n",
|
||||
"- Planowanie zakresu,\n",
|
||||
"- Definiowanie zakresu,\n",
|
||||
"- Tworzenie WBS (work breakdown structure),\n",
|
||||
"- Weryfikacja zakresu,\n",
|
||||
"- Kontrola zakresu.\n",
|
||||
"\n",
|
||||
"Zarządzanie zakresem projektu dotyczy:\n",
|
||||
"- Zakres produktu – czyli charakterystyki produktu tworzonego w ramach projektu; mierzony jest stopień uzyskania wymagań wyjściowych\n",
|
||||
"- Zakres projektu – zarządzanie dotyczy realizacji pracy w projekcie; mierzony stopień wykonanej pracy względem założeń.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"3) **Zarządzanie czasem**\n",
|
||||
"\n",
|
||||
"Zarządzanie czasem obejmuje szacowanie czasu realizacji poszczególnych zadań projektowych, opracowanie harmonogramu oraz monitorowanie i kontrolowanię odstępstw od harmonogramu. W szczególności obejmuje następujące procesy:\n",
|
||||
"- Definiowanie aktywności,\n",
|
||||
"- Sekwencjonowanie aktywności,\n",
|
||||
"- Szacowanie niezbędnych zasobów,\n",
|
||||
"- Szacowanie czasu trwania poszczególnych aktywności,\n",
|
||||
"- Harmonogramowanie,\n",
|
||||
"- Kontrola realizacji harmonogramu.\n",
|
||||
"- Zarządzanie czasem daje możliwość śledzenia czy aktywności projektu są realizowane zgodnie z planem oraz czy projekt zakończył się o czasie.\n",
|
||||
"\n",
|
||||
"4) **Zarządzanie kosztem**\n",
|
||||
"\n",
|
||||
"Zarządzanie kosztem pozwala na kontrolowanie tego czy projekt jest realizowany w ramach zaplanowanego budżetu. Obejmuje następujące procesy:\n",
|
||||
"- Szacowanie kosztów,\n",
|
||||
"- Budżetowanie kosztów,\n",
|
||||
"- Kontrolowanie kosztów.\n",
|
||||
"Zadanie dotyczy przede wszystkim zarządzania kosztami zasobów, jednakże wszelkie inne koszty również powinny być tutaj uwzględniane. Przy złożonych projektach może być konieczne aby przy zadaniu tym pracowała więcej niż jedna osoba, np. w kwestiach związanych z księgowością kierownik projektu może potrzebować wsparcia działu obsługi finansowej.\n",
|
||||
"\n",
|
||||
"5) **Zarządzanie jakością**\n",
|
||||
"\n",
|
||||
"Zarządzanie jakością zapewnia, że projekt spełnia oczekiwania klienta zapisane w wymaganiach. Zarządzanie obejmuje:\n",
|
||||
"- Zarządzanie jakością produktu projektu,\n",
|
||||
"- Zarządzanie jakością projektu.\n",
|
||||
"- Zarządzanie jakością obejmuje następujące procesy:\n",
|
||||
"- Planowanie jakości,\n",
|
||||
"- Wdrożenie i realizacja procedur utrzymania jakości,\n",
|
||||
"- Kontrola jakości.\n",
|
||||
"\n",
|
||||
"6) **Zarządzanie ryzykiem**\n",
|
||||
"\n",
|
||||
"W zarządzaniu projektami ryzyko to wydarzenie z przyszłości, które jeżeli zajdzie może wpłynąć pozytywnie, bądź negatywnie na projekt. W większości wypadków ryzyko rozumiane jest tradycyjnie tzn. jest powiązane ze stratami. Straty spowodowane przez ryzyko mogą być szacowane. Robi się to poprzez uwzględnienie dwóch czynników:\n",
|
||||
"- Prawdopodobieństwo, że dane zdarzenie zajdzie,\n",
|
||||
"- Skala strat jeżeli zdarzenie takie zajdzie.\n",
|
||||
"Analiza ryzyka związana z zarządzaniem projektem wymaga odpowiedzi na następujące pytania:\n",
|
||||
"- Jakie ryzyka są związane z projektem?\n",
|
||||
"- Jakie jest prawdopodobieństwo strat wynikających z tych ryzyk?\n",
|
||||
"- Ile straty takie będą kosztowały?\n",
|
||||
"- Jakie straty się pojawią jeżeli spełni się najgorszy scenariusz?\n",
|
||||
"- Jakie są rozwiązania alternatywne?\n",
|
||||
"- W jaki sposób straty mogą zostać zminimalizowane?\n",
|
||||
"- Czy rozwiązania alternatywne są obarczone ryzykiem?\n",
|
||||
"\n",
|
||||
"W projekcie zarządzamy jedynie tymi ryzykami, które mogą wpłynąć na projekt. Pomijamy inne ryzyka np. ryzyka biznesowe.\n",
|
||||
"Doświadczenie kierowników projektów mówi, że 10 podstawowych przyczyn odniesienia sukcesu przez projekt to:\n",
|
||||
"- Wsparcie zarządu,\n",
|
||||
"- Zaangażowanie klienta,\n",
|
||||
"- Doświadczenie kierownika projektu,\n",
|
||||
"- Jasne cele biznesowe projektu,\n",
|
||||
"- Zminimalizowany zakres,\n",
|
||||
"- Standardowa infrastruktura,\n",
|
||||
"- Przejrzyste wymagania,\n",
|
||||
"- Prowadzenie projektu metodami formalnymi,\n",
|
||||
"- Wiarygodne oszacowania,\n",
|
||||
"- Odpowiedni pracownicy.\n",
|
||||
"\n",
|
||||
"**Należy zatem przede wszystkim zarządzać ryzykiem w powyższych obszarach**.\n",
|
||||
"\n",
|
||||
"7) **Zarządzanie zasobami ludzkimi**\n",
|
||||
"\n",
|
||||
"Zarządzanie zasobami ludzkimi (HR – human resources) obejmują wszystkie procesy związane z zarządzaniem zespołami ludzkimi, w tym leadership, szkolenia, rozwiązywanie konfliktów, zwiększanie efektywności pracy, itp. Zarządzanie obejmuje:\n",
|
||||
"- Planowanie wykorzystania zasobów ludzkich,\n",
|
||||
"- Pozyskanie zespołów ludzkich,\n",
|
||||
"- Budowa zespołu projektowego,\n",
|
||||
"- Zarządzanie zespołem projektowym.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"8) **Zarządzanie komunikacją**\n",
|
||||
"\n",
|
||||
"Zarządzanie komunikacją obejmuje wszystkie te aktywności, które dotyczą komunikacji w projekcie. \n",
|
||||
"- Zarządzanie to obejmuje:\n",
|
||||
"- Planowanie komunikacji,\n",
|
||||
"- Dystrybucja informacji,\n",
|
||||
"- Raportowanie o postępach,\n",
|
||||
"- Zarządzanie intersariuszami.\n",
|
||||
"\n",
|
||||
"9) **Zarządzanie procesami zaopatrzenia**\n",
|
||||
"\n",
|
||||
"Zarządzanie procesami zaopatrzenia dotyczy wszystkich aktywności związanych z nabywaniem produktów niezbędnych do realizacji projektu. Proces ten obejmuje:\n",
|
||||
"- Planowanie zakupów,\n",
|
||||
"- Planowanie kontraktów,\n",
|
||||
"- Składanie zamówień,\n",
|
||||
"- Wybieranie dostawców,\n",
|
||||
"- Zarządzanie kontraktami,\n",
|
||||
"- Zamykanie kontraktów.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5. Zadania proponowane na laboratoria\n",
|
||||
"\n",
|
||||
"### Zadanie 1.\n",
|
||||
"\n",
|
||||
"Przygotuj dokument *Zakres projektu*.\n",
|
||||
"\n",
|
||||
"Zakres projektu to dokument, zawierający następujące składowe:\n",
|
||||
"- Cele projektu\n",
|
||||
"- Opis produktu oczekiwanego przez klienta\n",
|
||||
"- Wymagania projektowe\n",
|
||||
"- Granice projektu\n",
|
||||
"- Kryteria akceptacji produktu\n",
|
||||
"- Ograniczenia projektowe\n",
|
||||
"- Założenia projektowe\n",
|
||||
"- Początkowa organizacja projektu\n",
|
||||
"- Ryzyka zidentyfikowane w fazie początkowej\n",
|
||||
"- Kamienie milowe do osiągnięcia\n",
|
||||
"- Ograniczenia finansowe\n",
|
||||
"- Budżet projektu\n",
|
||||
"\n",
|
||||
"### Zadanie 2.\n",
|
||||
"\n",
|
||||
"Przygotuj strukturę WBS (ang. Work Breakdown Structure) projektu.\n",
|
||||
"\n",
|
||||
"Struktura WBS to hierarchiczna struktura opisująca pracę, która powinna zostać zrealizowana przez zespoły projektowe w celu osiągnięcia celów projektu oraz uzyskania produktów projektu. Struktura WBS pokrywa cały zakres projektu. Elementami składowymi struktury WBS są zadania do wykonania. Na strukturę WBS powinny składać się na tyle małe zadania aby możliwe było łatwe ich planowanie, realizowanie, monitorowanie oraz kontrolowanie. W PMBOK przyjmuje się, że na najniższym poziomie hierarchii struktury WBS znajduje się zawsze pakiet pracy (ang. work package).\n",
|
||||
"\n",
|
||||
"### Zadanie 3.\n",
|
||||
"\n",
|
||||
"Przygotuj harmonogram projektu w postaci diagramu Gantta lub PDM (ang. precendence diagramming method).\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Jacek Marciniak",
|
||||
"email": "jacekmar@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"org": null,
|
||||
"subtitle": "6. Metodyka PMBOK",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2022"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 1
|
||||
}
|
||||
@ -483,7 +483,7 @@
|
||||
],
|
||||
"metadata": {
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3 (ipykernel)",
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
@ -497,7 +497,7 @@
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.10.8"
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"org": null
|
||||
},
|
||||
|
||||
BIN
obrazy/iteracyjnosc.png
Normal file
BIN
obrazy/iteracyjnosc.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 8.4 KiB |
BIN
obrazy/trojkat_zakresu.png
Normal file
BIN
obrazy/trojkat_zakresu.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4.0 KiB |
Loading…
Reference in New Issue
Block a user