Merge branch 'master' of https://git.wmi.amu.edu.pl/AITech/aitech-pbr2022
This commit is contained in:
commit
d053737be0
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
|
||||
}
|
||||
446
.ipynb_checkpoints/07_metodyka_prince2-checkpoint.ipynb
Normal file
446
.ipynb_checkpoints/07_metodyka_prince2-checkpoint.ipynb
Normal file
File diff suppressed because one or more lines are too long
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
|
||||
}
|
||||
@ -614,7 +614,7 @@
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"display_name": "Python 3 (ipykernel)",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
@ -629,7 +629,7 @@
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
"version": "3.10.8"
|
||||
},
|
||||
"subtitle": "05. Metodologia Prince2Agile[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
|
||||
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
|
||||
}
|
||||
598
07_metodyka_prince2.ipynb
Normal file
598
07_metodyka_prince2.ipynb
Normal file
@ -0,0 +1,598 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {
|
||||
"id": "P3B5edVlpfhm"
|
||||
},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "raw",
|
||||
"metadata": {
|
||||
"id": "TjKLqiKKpfhn"
|
||||
},
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "lJs0WcXzpfho"
|
||||
},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 6. <i>Metodyka zarządania PRINCE2® </i>[wykład]</h2> \n",
|
||||
"<h3>Tomasz Piłka (2022)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "LGcbq5Wmpfhy"
|
||||
},
|
||||
"source": [
|
||||
"## 1. Metodyka wytworzenia oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "L6Of2X4kpfhy"
|
||||
},
|
||||
"source": [
|
||||
"\n",
|
||||
"### Metodyka wytworzenia oprogramowania\n",
|
||||
"\n",
|
||||
"Metodyka wytwarzania oprogramowania jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu.\n",
|
||||
"\n",
|
||||
"Metodyka wytwarzania oprogramowania jest powiązana z notacją służącą do dokumentowania wyników faz projektu (pośrednich, końcowych) jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami a klientem.\n",
|
||||
"\n",
|
||||
"Metodyka ustala:\n",
|
||||
"\n",
|
||||
"- fazy projektu, role uczestników projektu,\n",
|
||||
"- modele tworzone w każdej z faz,\n",
|
||||
"- scenariusze postępowania w każdej z faz,\n",
|
||||
"- reguły przechodzenia od fazy do następnej fazy,\n",
|
||||
"- notacje, których należy używać,\n",
|
||||
"- dokumentację powstającą w każdej z faz..\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "iPmY6j86muTD"
|
||||
},
|
||||
"source": [
|
||||
"## 2. PRINCE2® (**P**roject **IN** **C**ontrolled **E**nvironment)\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "jY-ZfAFVpfhz"
|
||||
},
|
||||
"source": [
|
||||
"### PRINCE2® - geneza\n",
|
||||
"\n",
|
||||
"Metoda PRINCE2 powstała W Wielkiej Brytanii. Początkiem była metodyka PROMT, 1975 rok. \n",
|
||||
"\n",
|
||||
"Metoda ta przybrała bardziej współczesny wymiar w 1979 roku dzięki Central Computer and Telecommunications Agency (CCTA). Był to ówczesny standard stosowany **we wszystkich projektach informatycznych** wykonywanych dla potrzeb Rządu Wielkiej Brytanii.\n",
|
||||
"\n",
|
||||
"CCTA przekształciła metodę PROMT do PRINCE (**Project IN Controlled Environment**) w 1989 roku, by w 1996 roku nastąpił kolejny etap rozwoju i unowocześnienie metodyki do znanej obecnie PRINCE2. Kolejne wersje pojawiały się w roku 2005, 2009.\n",
|
||||
"\n",
|
||||
"W 2017 roku na podstawie doświadczeń wielu specjalistów z zakresu zarządzania projektami AXELOS po raz kolejny zaktualizował metodykę PRINCE2. \n",
|
||||
"\n",
|
||||
"Nowa wersja kładzie szczególny nacisk na dostosowanie sposobu zarządzania projektem do sytuacji, w której ma ono miejsce i jest poparta licznymi przykładami. W nowej edycji pojawiły się również wymogi metodyki PRINCE2 dla poszczególnych tematów, co stanowi rozwinięcie nakazowych pryncypiów.\n",
|
||||
"\n",
|
||||
"Metodyka PRINCE2 jest metodą kompleksową. W grupie metodyk zaliczana jest do **podejścia klasycznego**. Oznacza, to że PRINCE2 porusza problem bardzo dokładnie, a **sposób realizacji projektu jest określony przed przystąpieniem do jego realizacji**. \n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "qlaRUn4spfhz"
|
||||
},
|
||||
"source": [
|
||||
"### PRINCE2® - budowa\n",
|
||||
"\n",
|
||||
"Metodyka PRINCE2® przedstawia zarządzanie projektem jako cztery zintegrowane elementy:\n",
|
||||
"\n",
|
||||
" - pryncypia,\n",
|
||||
" - tematy,\n",
|
||||
" - procesy,\n",
|
||||
" - środowisko projektowe.\n",
|
||||
"\n",
|
||||
"![img](./obrazy/07_prince_tematy.jpg \"Elementy w meodyce Prince2\")"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"## 3. PRINCE2® - Pryncypia\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "gRo2N7Wopfhz"
|
||||
},
|
||||
"source": [
|
||||
"Celem PRINCE2® jest dostarczenie metodyki zarządzania projektami, którą można zastosować niezależnie od zakresu projektu, rodzaju, organizacji, położenia geograficznego czy kultury. Jest to możliwe, ponieważ metodyka PRINCE2® oparta jest na pryncypiach. \n",
|
||||
"\n",
|
||||
"Pryncypia stanowią podstawowe zasady, nakazy, które powstały w wyniku przeszłych doświadczeń w zakresie zarządzania projektami. Wyróżnia się siedem pryncypiów opartych na dobrych praktykach, które wspólnie tworzą strukturę PRINCE2.\n",
|
||||
"\n",
|
||||
"Siedem pryncypiów PRINCE2®:\n",
|
||||
"1. ciągła zasadność biznesowa,\n",
|
||||
"2. korzystanie z doświadczeń,\n",
|
||||
"3. zdefiniowane role i obowiązki,\n",
|
||||
"4. zarządzanie etapowe,\n",
|
||||
"5. zarządzanie z wykorzystaniem tolerancji,\n",
|
||||
"6. koncentracja na produktach,\n",
|
||||
"7. dostosowanie do warunków projektu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-info alert-danger\">\n",
|
||||
" Jeżeli projekt nie stosuje się do któregokolwiek z nich to nie jest on zarządzany zgodnie z metodyką PRINCE2 \n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"---\n",
|
||||
"Omówmy poszczególne prycypia: \n",
|
||||
"\n",
|
||||
"**(1) Ciągła zasadność biznesowa** (ang. *continued business justification* )\n",
|
||||
"> Uzasadnienie biznesowe stanowi najważniejszy dokument i jest aktualizowany w każdym etapie projektu aby zapewnić, że jego realizacja jest ciągle wykonalna. Projekt realizowany zgodnie z PRINCE2 ma ciągle ważne uzasadnienie biznesowe\n",
|
||||
"\n",
|
||||
"**(2) Korzystanie z doświadczeń** (ang. *learn from experience* ) \n",
|
||||
"> Każdy projekt utrzymuje Raport Doświadczeń oraz korzysta z doświadczeń innych projektów zarówno zakończonych jak też i trwających Członkowie zespołu uczą się wcześniejszych doświadczeń\n",
|
||||
"\n",
|
||||
"**(3) Zdefiniowane role i obowiązki** (ang. *defined roles and responsibiliteis*) \n",
|
||||
"> PRINCE2 dokładnie definiuje role oraz zakres odpowiedzialności dla każdej z tych ról. Struktura organizacyjna uwzględnia interesy biznesu, użytkowników oraz dostawcy.\n",
|
||||
"\n",
|
||||
"**(4) Zarządzanie etapowe** (ang. *Manage by stage* )\n",
|
||||
"> Projekt jest planowany, monitorowany oraz kontrolowany etapowo.\n",
|
||||
"\n",
|
||||
"**(5) Zarządzanie z wykorzystaniem tolerancji** (ang. *Manage by exception*)\n",
|
||||
"> Unika się regularnych spotkań zamiast tego paczki zadań są przypisywane członkom zespołu z określoną tolerancją dla poszczególnych aspektów. Dla każdego z celów projektu określone są tolerancje, które określają granicę dla delegowanych uprawnień\n",
|
||||
"\n",
|
||||
"**(6) Koncentracja na produktach** (ang. *Focus on products*)\n",
|
||||
"> Realizacja projektu jest skoncentrowana na zdefiniowaniu oraz dostarczaniu produktów (spełniających określone dla nich wymagania jakościowe).\n",
|
||||
"\n",
|
||||
"**(7) Dostosowanie do warunków projektu** (ang. *Tailor to suit the project environment*)\n",
|
||||
"> PRINCE2 powinien być zawsze dostosowana do konkretnego projektu, uwzględniając jego warunki, wielkość, złożoność, istotność, możliwości oraz ryzyka.\n",
|
||||
"\n",
|
||||
"---\n",
|
||||
"Metodykę PRINCE2® można stosować w kazdym projekcie, przykładem może być następujące wprowadzenie\n",
|
||||
"\n",
|
||||
"*Książę postanowił poślubić księżniczkę. Zaplanowano ślub w katedrze, zabawy dla mieszkańców księstwa i wystawne wesele w zamku na 1000 osób. Książę wyznaczył swojego ochmistrza do roli kierownika projektu „Wesele Księcia”... aby zobrazować wykorzystanie pryncypiów przeczytaj wpis na blogu* [Wesele Księcia, czyli jak Pryncypia PRINCE2® wprowadzają porządek](https://inprogress.pl/blog/wesele-ksiecia-czyli-jak-pryncypia-prince2-wprowadzaja-porzadek/)\n",
|
||||
"<div class=\"alert alert-info alert-success\"> </div>\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"## 4. PRINCE2® - Tematy\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "NnYKjk3Qpfh0"
|
||||
},
|
||||
"source": [
|
||||
"Tematy PRINCE2 to siedem różnych aspektów, którymi należy się zajmować i które należy kontrolować. Tematami PRINCE2 są:\n",
|
||||
"\n",
|
||||
"1. Uzasadnienie Biznesowe, \n",
|
||||
"1. Organizacja,\n",
|
||||
"1. Jakość,\n",
|
||||
"1. Plany,\n",
|
||||
"1. Ryzyko,\n",
|
||||
"1. Zmiana, \n",
|
||||
"1. Postęp.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"![img](./obrazy/07_prince_tematy.jpg \"Tematy w Prince2\")\n",
|
||||
"---\n",
|
||||
"**(1) Uzasadnienie biznesowe** (ang. *Business Case*) \n",
|
||||
"\n",
|
||||
"*określenie mierzalnych celów, które uzasadnia zaangażowanie określonych zasobów*\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-info alert-danger\">\n",
|
||||
" <span style=\"color:red;weight:bold\">Dlaczego? </span>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"> Projekt zaczyna się od pomysłu, o którym sądzi się, że ma potencjalną wartość dla zainteresowanej organizacji. Temat ten opisuje, w jaki sposób ten pomysł jest przekształcany w zasadną propozycję inwestycji dla organizacji oraz jak zarządzanie projektem utrzymuje koncentrację na celach organizacji w trakcie całego projektu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"**(2) Organizacja** (ang. *Organization*) \n",
|
||||
"\n",
|
||||
"*definiuje role oraz odpowiedzialności poszczególnych osób w powołanym na czas realizacji projektu zespole.*\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-info alert-danger\">\n",
|
||||
" <span style=\"color:red;weight:bold\">Kto? </span>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"> Organizacja sponsorująca projekt musi przekazać związane z nim prace menedżerom, którzy będą za niego odpowiedzialni i będą nim kierowali aż do jego zakończenia. Temat ten opisuje role i obowiązki, w powołanym na pewien czas zespole zarządzania projektem zgodnym z PRINCE2, niezbędne dla efektywnego zarządzania projektem.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"**(3) Jakość** (ang. *Quality*)\n",
|
||||
"\n",
|
||||
"*zapewnienie, że wszystkie produkty spełniają postawione oczekiwania jakościowe (uzgodnione jakościowe atrybuty produktów)*\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-info alert-danger\">\n",
|
||||
" <span style=\"color:red;weight:bold\">Co? </span>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"> Początkowy pomysł jest rozumiany jedynie w ogólnym zarysie. Ten temat PRINCE2 pokazuje jak taki zarys jest rozwijany, aby wszyscy uczestnicy uzgodnili jakościowe atrybuty produktów, które mają być dostarczone, a następnie także, w jaki sposób zarządzanie projektem zapewni, że uzgodnione wymagania zostaną następnie spełnione.\n",
|
||||
"\n",
|
||||
"**(4) Plany** (ang. *Plans*) \n",
|
||||
"\n",
|
||||
"*są układane oraz zatwierdzane przed rozpoczęciem kolejnego etapu realizacji projektu. Temat plany opisuje szczegółowo kroki oraz techniki jakie powinny być zastosowane*\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-info alert-danger\">\n",
|
||||
" <span style=\"color:red;weight:bold\">Jak? Za ile? Kiedy? Kim? </span>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"> Projekty PRINCE2 przebiegają zgodnie z szeregiem zatwierdzonych planów. Temat ten uzupełnia temat Jakość opisując kroki wymagane do sporządzenia planów oraz techniki PRINCE2, które powinny zostać zastosowane.\n",
|
||||
"\n",
|
||||
"**(5) Ryzyko** (ang. *Risk*)\n",
|
||||
"\n",
|
||||
"*Utrzymywanie ryzyka na określonym poziomie, który jest akceptowalny. W jaki sposób osoby kierujące projektem zarządzają ryzykami zawartymi w planach.*\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-info alert-danger\">\n",
|
||||
" <span style=\"color:red;weight:bold\">Co, jeżeli? </span>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"> Z projektami związane jest zwykle większe ryzyko niż z ustabilizowanymi działaniami operacyjnymi. Ten temat dotyczy sposobu, w jaki kierownictwo projektu zarządza niepewnościami zawartymi w planach i w szeroko rozumianym środowisku projektu.\n",
|
||||
"\n",
|
||||
"**(6) Zmiana** (ang. *Change*) \n",
|
||||
"\n",
|
||||
"*Zarządzanie zmianami, a więc jak postępować z tymi zagadnieniami, które wykraczają poza zatwierdzony już aspekty projektu. Zmiany mogą wynikać z nieprzewidzianych problemów, wniosków o wprowadzenie zmian lub wykryciu wad jakościowych produktów*\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-info alert-danger\">\n",
|
||||
" <span style=\"color:red;weight:bold\">Jaki jest wpływ? </span>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"> Temat ten opisuje, w jaki sposób ocenia się i postępuje z zagadnieniami, które mają potencjalny wpływ na dowolny zatwierdzony aspekt projektu (jego plany lub wytworzone produkty)\n",
|
||||
"\n",
|
||||
"**(7) Postępy** (ang. *Progress*)\n",
|
||||
"\n",
|
||||
"*mierzenie postępów w realizacji poszczególnych produktów. Monitorowanie wykonania planów oraz procedury eskalacji w przypadku gdy realizacja zaczyna odbiegać od planów*\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-info alert-danger\">\n",
|
||||
" <span style=\"color:red;weight:bold\">Gdzie teraz jesteśmy? Dokąd zmierzamy? Czy kontynuować? </span>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"> Ten temat PRINCE2 dotyczy oceny bieżącej zasadności planów. Wyjaśnia on proces decyzyjny dotyczący zatwierdzania planów, monitorowanie faktycznego wykonania oraz proces przekazywania spraw na wyższy szczebel zarządzania w przypadku, gdy zdarzenia przebiegają niezgodnie z planem.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"## 5. PRINCE2® - Role\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"PRINCE2 jest **ustrukturyzowanym zarządzaniem projektem**. Oznacza to, że metodyka ta określa kilka procesów, które opisują wszystkie działania podejmowane od rozpoczęcia aż do zakończenia projektu. Z każdym procesem związana jest odpowiedzialność ściśle określonej osoby.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"PRINCE2 zakłada występowanie następujących ról:\n",
|
||||
"1. Komitet Sterujący (ang. Project Board)\n",
|
||||
"1. Przewodniczący (Executive)\n",
|
||||
"1. Główny Użytkownik (Senior User)\n",
|
||||
"1. Główny Dostawca (Senior Supplier)\n",
|
||||
"1. Kierownik Projektu (Project Manager)\n",
|
||||
"1. Kierownik Zespołu (Team Manager)\n",
|
||||
"1. Nadzór Projektu (Project Assurance)\n",
|
||||
"1. Wsparcie Projektu (Project Support)\n",
|
||||
"\n",
|
||||
"z wykorzystaniem któych, można przedstawić następującą strukturę organizacyjną projektu \n",
|
||||
"![img](./obrazy/07_prince_strukt_organizac_projektu.jpg \"Struktura organizacyjna projektu w Prince2\")\n",
|
||||
"\n",
|
||||
"Rolę kierownika projektu obejmuje osoba, która organizuje i steruje projektem. Do jego zadań należy:\n",
|
||||
" - wyznaczenie specjalistów do wykonania prac związanych z realizacją projektu. \n",
|
||||
" - daje także gwarancję, że prace będą wykonane terminowo i zgodnie z przyjętymi założeniami.\n",
|
||||
" \n",
|
||||
"Wyróżniamy ponadto **klienta**, zwanego także **przewodniczącym komitetu sterującego**, oraz **użytkownika**. Klient to osoba, która płaci za realizację projektu. Użytkownik natomiast to osoba, która będzie korzystać z produktu lub rezultatu projektu. W niektórych przypadkach może (ale nie musi) być to ta sama osoba.\n",
|
||||
"\n",
|
||||
"Kolejna postacią jest **dostawca (lub specjalista)**\n",
|
||||
"Jest to osoba posiadająca odpowiednie kompetencje oraz specjalistyczne umiejętności, które wnosi do realizowanego projektu.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"## 6. PRINCE2® - Komitet sterujacy i poziomy zarządzania\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"### Komitet sterujący \n",
|
||||
"\n",
|
||||
"*Komitet Sterujący** to niezbędny element każdego projektu realizowanego w PRINCE2. W jego skład wchodzi \n",
|
||||
" - klient (lub przewodniczący),\n",
|
||||
" - reprezentant strony użytkownika (Główny Użytkownik)\n",
|
||||
" - reprezentant dostawcy lub specjalisty (Główny Dostawca).\n",
|
||||
" \n",
|
||||
"Zadaniem Komitetu Sterującego jest podejmowanie decyzji niezbędnych kierownikowi projektu, by **rozwiązywać problemy i kontynuować realizację projektu**. Ponadto Komitet Sterujący **odbiera od Kierownika Projektu regularne raporty o stanie prac**.\n",
|
||||
"\n",
|
||||
"**Przewodniczący Komitetu Sterującego** jest odpowiedzialny za nadzór ze strony biznesu.\n",
|
||||
" - Chce mieć pewność, że biznesowe aspekty projektu są prawidłowe.\n",
|
||||
" - Nieustannie zadaje pytanie: Czy projekt jest wart realizacji?\n",
|
||||
" \n",
|
||||
"**Główny użytkownik** jest odpowiedzialny za nadzór ze strony użytkowników.\n",
|
||||
"Chce mieć pewność, że projekt dostarczy właściwe produkty spełniające wymagania.\n",
|
||||
"Nieustannie zadaje pytanie: Czy produkt będzie działał jak tego oczekujemy?\n",
|
||||
"\n",
|
||||
"**Główny Dostawca** jest odpowiedzialność za nadzór ze strony dostawców.\n",
|
||||
"Chce mieć pewność, że produkty zostaną dostarczone zgodnie z oczekiwaniami i że na potrzeby projektu są dostępni właściwi ludzie i materiały.\n",
|
||||
"Nieustannie zadaje pytanie: Czy może to być wykonane w ramach założonego kosztu, czasu i innych ograniczeń?\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"### Poziomy zarządzania\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"![img](./obrazy/07_prince_poziomy_zarzadzania.jpg \"Poziomy zarządzania w Prince2\")\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"Cztery poziomy w strukturze zarządczej projektu to:\n",
|
||||
" - Poziom kierownictwa organizacji lub programu.\n",
|
||||
" - Poziom zarządzania strategicznego,\n",
|
||||
" - Poziom zarządzania operacyjnego,\n",
|
||||
" - Poziom dostarczania produktów.\n",
|
||||
"\n",
|
||||
"**Poziom: Kierownictwa organizacji lub programu**\n",
|
||||
"\n",
|
||||
"Z tego poziomu przychodzi zlecenie przygotowania projektu i na tym poziomie nominowany jest Przewodniczący Komitetu Sterującego. Decydenci na tym poziomie ustalają, jak Komitet Sterujący będzie ich informował o przebiegu projektu i jakie tolerancje na projekt będzie miał do dyspozycji.\n",
|
||||
"\n",
|
||||
"**Poziom: Zarządzania strategicznego projektem (Komitet Sterujący)**\n",
|
||||
"\n",
|
||||
"Komitet Sterujący odpowiada za strategiczne zarządzanie projektem i odpowiada decyzyjnie za jego sukces. Do obowiązków Komitetu Sterującego należy:\n",
|
||||
" - Przydział zasobów i zatwierdzanie głównych planów – Plan Projektu, Plan Etapu.\n",
|
||||
" - W przypadku przewidywania, że zostaną przekroczone tolerancje zatwierdzanie odchyleń.\n",
|
||||
" - Dawanie zgody na realizację etapów zarządczych i zatwierdzanie ich zakończenia.\n",
|
||||
" - Komunikacja z Interesariuszami w tym z Kierownictwem organizacji lub programu.\n",
|
||||
"Pracę Komitetu Sterującego opisuje proces Zarządzanie Strategiczne Projektem.\n",
|
||||
"\n",
|
||||
"**Poziom zarządzania operacyjnego (Kierownik Projektu)**\n",
|
||||
"\n",
|
||||
"Kierownik Projektu jest odpowiedzialny za operacyjne (codzienne) zarządzanie projektem. Jego podstawowym obowiązkiem jest dbanie o to, aby projekt wytwarza ł wymagane produkty przy założonych celach, którymi są: czas, koszt, jakość, zakres, ryzyko i korzyści.\n",
|
||||
"\n",
|
||||
"**Poziom dostarczania produktów (Kierownik Zespołu)**\n",
|
||||
"\n",
|
||||
"Członkowie zespołów odpowiadają za dostarczenie produktów projektu o określonej, jakości w ramach uzgodnionego kosztu i czasu. Kierownik zespołu jest upoważniony i odpowiada za przygotowanie Panu Zespołu i zarządzanie zespołem tak, aby wymagane produkty były dostarczone. Działania zarządcze związane z dostarczaniem produktów specjalistycznych opisuje proces Zarządzanie Dostarczaniem Produktów.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"## 7. PRINCE2® - Procesy\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"PRINCE2 oparta jest na procesach, które definiują konkretne działania zaprojektowanych w celu osiągnięcia określonego celu. W PRINCE2 wyróżnione jest 7 procesów:\n",
|
||||
"\n",
|
||||
"1. **Przygotowanie projektu - PP** (Starting up a project - SU)\n",
|
||||
"1. **Zarządzanie strategiczne projektem - ZS** (Directing a project - DP)\n",
|
||||
"1. **Inicjowanie Projektu - IP** (Initiating a project - IP)\n",
|
||||
"1. **Sterowanie Etapem - SE** (Controlling a stage - CS)\n",
|
||||
"1. **Zarządzanie wytwarzaniem produktów - WP** (Managing product delivery - MP)\n",
|
||||
"1. **Zarządzanie zakresem Etapu - ZE** (Managing a stage boundary - SB)\n",
|
||||
"1. **Zamykanie projektu - ZP** (Closing a project - CP)\n",
|
||||
"\n",
|
||||
"---\n",
|
||||
"\n",
|
||||
"**(1) Przygotowanie Projektu** (ang. Starting up a procect) \n",
|
||||
"Przed rozpoczęciem projektu należy zweryfikować czy projekt jest zasadny oraz wykonalny. Głównym produktem jest opracowanie Założeń Projektu, na podstawie którego Komitet Sterujący decyduje o zainicjowaniu projektu\n",
|
||||
"\n",
|
||||
"**(2) Zarządzanie strategoczine projektem** (ang. Directing a Project) \n",
|
||||
"jest to proces w którym Komitet Sterujący sprawuje ogólną kontrolę nad całym projektem oraz podejmuje kluczowe decyzje\n",
|
||||
"\n",
|
||||
"**(3) Inicjowanie projektu** (ang. Initiating a Project) \n",
|
||||
"Etap ten służy do szczegółowego zaplanowania. Planowane są strategie zarządzania projektem oraz mechanizmy sterowania, opracowywane jest Uzasadnienie Biznesowe. Etap ten kończy się sporządzeniem Dokumentacji Inicjowania Projektu.\n",
|
||||
"\n",
|
||||
"**(4) Sterowanie Etapem** (ang. Controlling a Stage ) \n",
|
||||
"za kolejne etapy realizacji projektu odpowiedzialny jest Kierownik Projektu. W ramach etapów Kierownik przydziela prace do wykonana oraz dba o to aby opracowane produkty spełniały określone wymagania jakościowe, Kierownik Projektu dba o postępy były zgodne z zatwierdzonym planem.\n",
|
||||
"\n",
|
||||
"**(5) Zarządzanie Dostarczaniem Produktów** (ang. Managing Product elivery ) \n",
|
||||
"w tym procesie Kierownik Zespołu oraz członkowie zespołów realizują przydzielone im Grupy Zadań\n",
|
||||
"\n",
|
||||
"**(6) Zarządzanie Końcem Etapu** (ang. Managing a Stage Boundary) \n",
|
||||
"służy do sporządzenia raportu z wyników etapu, aktualizacji Uzasadnienia Biznesowego oraz zaplanowaniu szczegółowym następnego etapu. Kierownik Projektu dostarcza informację dla Komitetu Sterującego niezbędne do podjęcia decyzji o realizacji następnego etapu\n",
|
||||
"\n",
|
||||
"**(7) Zamykanie Projektu** (ang. Closing a Project) \n",
|
||||
"proces ten jest podobny do procesu Zarządzania Końcem Etapu przy czym tu nie są tworzone już plany kolejnego etapu. Planowane jest tylko jak będą przebiegały przeglądy korzyści.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"## 8. PRINCE2® - Środowisko, dokumentacja\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_",
|
||||
"jp-MarkdownHeadingCollapsed": true,
|
||||
"tags": []
|
||||
},
|
||||
"source": [
|
||||
"### Środowisko w PRINCE2®\n",
|
||||
"\n",
|
||||
"Istotną zasadą PRINCE2 jest jej dostosowanie do danego projektu, aby odpowiadała jego warunków. Dostosowanie **nie może polegać na pomijaniu** jakichkolwiek elementów PRINCE2, ale na adaptacji metodyki do specyficznych warunków projektu. Należy uwzględnić **standardy firmowe** oraz **skalę projektu**.\n",
|
||||
"Dostosowanie polega w szczególności na:\n",
|
||||
" - dostosowaniu tematów\n",
|
||||
" - adaptację pojęć i języka\n",
|
||||
" - dostosowanie Opisów Produktów dla produktów zarządczych\n",
|
||||
" - adaptację opisów i ról\n",
|
||||
" - dostosowanie procesów, aby były spójny ze wszystkimi powyższymi punktami\n",
|
||||
" - zapisanie wszystkich ustaleń w Dokumentacji Inicjowania Projektu\n",
|
||||
"\n",
|
||||
"### Dokumentacja w PRINCE2®\n",
|
||||
"\n",
|
||||
"Jednolity system dokumentacji wprowadza ujednolicony system dokumentacji, opierający się na 4 rodzajach dokumentów\n",
|
||||
" - Teczka projektu \n",
|
||||
" - Teczka etapu (teczki etapów) \n",
|
||||
" - Teczka jakości \n",
|
||||
" - Teczka merytoryczna\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"## 9. PRINCE2® - Wady, zalety i wskazówki "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"### PRINCE2® - Zalety\n",
|
||||
"\n",
|
||||
" - ujednolicona terminologia i nazewnictwo pozwala w dużym stopniu wyeliminować problemy komunikacyjne.\n",
|
||||
" - metodyka może być zastosowana w projekcie dowolnego rodzaju projektu\n",
|
||||
" - dzięki precyzyjnemu określeniu ról i obowiązków uporządkowana jest cała struktura odpowiedzialności, eskalacji problemów oraz komunikacji\n",
|
||||
" - jedną z podstawowych zasad jest zasada zarządzania przez wyjątki - pozwala to na eliminację niepotrzebnego zaangażowania wyższego kierownictwa\n",
|
||||
" - ustandaryzowanie i kompletność dokumentacji jest zapewniona poprzez dostarczenia gotowych szablonów dla wszystkich wymaganych dokumentów\n",
|
||||
"\n",
|
||||
"### PRINCE2® - Wady\n",
|
||||
"\n",
|
||||
" - nie pozwala na poziom elastyczności oferowany przez podejście Agile - zmiany mogą być trudne do wdrożenia, ponieważ muszą przejść przez łańcuch zatwierdzeń i wymagają wielokrotnej aktualizacji dokumentacji\n",
|
||||
" - podczas gdy proces może być dostosowany do konkretnego projektu, generalnie utrzymywanie wielu dokumentów i dzienników wymaga dodatkowego czasu i wysiłku\n",
|
||||
" - syndrom **PINO** (Prince In Name Only, tzn. PRINCE2 tylko z nazwy), wybierając bez głębszej analizy tylko niektóre składniki metodyki nie zwracając uwagi na podstawowe zasady\n",
|
||||
" - PRINCE2 zwraca uwagę na potrzebę dobrej organizacji i regularną wymianę informacji pomiędzy interesariuszami, co może być odbierane jako zachęta do ciągłych bezproduktywnych spotkań zabierających czas niezbędny na rzeczywistą pracę.\n",
|
||||
"\n",
|
||||
"### Kilka wskazówek: PRINCE2® stosować czy nie stosować? \n",
|
||||
"Przy wyborze metody czy techniki w zarządzaniu projektami, zdrowy rozsądek jest Twoim największym sprzymierzeńcem. Metoda PRINCE2 posiada zarówno zalety jak i ograniczenia. By mówić o projekcie prowadzonym w standardzie PRINCE2 należy być konsekwentnym i dostosować się do wszystkich wymagań stawianych przez tą metodę. \n",
|
||||
"\n",
|
||||
"W sytuacji, gdy występują pewne ograniczenia by zarządzać przy użyciu tej metody może warto wyciągnąć z niej najbardziej przydatne narzędzia bądź techniki do zarządzania Twoim projektem. \n",
|
||||
"\n",
|
||||
"**Jedna i druga droga musi zaprowadzić Cię do skutecznej realizacji projektu i dostarczenia obiecanego produktu.**\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "XmY-EAr0pcU_"
|
||||
},
|
||||
"source": [
|
||||
"## 10. Bibliografia\n",
|
||||
"\n",
|
||||
"1. Borek A. (2014), PRINCE2 - Metodyka zarządzania projektami, Studia i Materiały Instytutu Transportu i Handlu Morskiego, nr 11\n",
|
||||
"1. Bradley K. (2002), Podstawy metodyki PRINCE2, Centrum Rozwiązań Menedżerskich S.A., Warszawa\n",
|
||||
"1. Ferguson C. (2011), PRINCE2® for small-scale projects, AXELOS, White Paper, September 2011\n",
|
||||
"1. Rankins G.J., Kearns M. (2008), Integrating PRINCE2 and Scrum for successful new product development, the Australian Institute of Project Management National Conference, Canberra\n",
|
||||
"1. Wideman R. Max (2002), Comparing PRINCE2 with PMBoK, AEW Services, Vancouver\n",
|
||||
"1. Wyrozębski P. (2011), Metodyki zarządzania projektami, wyd. Bizarre, Warszawa\n",
|
||||
"1. Strona internetowa metodyki PRINCE2, Axelos\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "DBJy5KNHpfh4"
|
||||
},
|
||||
"source": [
|
||||
"## 11. Zadania (proponowane do realizacji na laboratoriach)\n",
|
||||
"\n",
|
||||
"### Zadanie 1. Pryncypia w Twoim projekcie \n",
|
||||
"Zdefiniuj jak rozumiesz i czym są pryncypia w Twoim projekcie, jeżeli byłby realizowany zgodnie z metodyką Prince2\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"### Zadanie 2. Tematy w Twoim projekcie \n",
|
||||
"Zdefiniuj jak rozumiesz i czym są tematy w Twoim projekcie, jeżeli byłby realizowany zgodnie z metodyką Prince2\n",
|
||||
"\n",
|
||||
"### Zadanie 3. Role w projekcie według metodyki Prince2\n",
|
||||
"\n",
|
||||
"Przydzielcie osobom wszystkie role według metodyki Prince2. Wyjaśnijcie, jak te role będą przekładać się na konkretne czynności w Waszym projekcie\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Jacek Marciniak",
|
||||
"colab": {
|
||||
"provenance": []
|
||||
},
|
||||
"email": "jacekmar@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3 (ipykernel)",
|
||||
"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.11.0"
|
||||
},
|
||||
"org": null,
|
||||
"subtitle": "6. Metodyka PMBOK",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2022"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
506
08_ci_cd_uczenie_maszynowe.ipynb
Normal file
506
08_ci_cd_uczenie_maszynowe.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
|
||||
}
|
||||
496
09_zarzadzanie_bezpieczenstwem_aplikacji.ipynb
Normal file
496
09_zarzadzanie_bezpieczenstwem_aplikacji.ipynb
Normal file
@ -0,0 +1,496 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "purple-committee",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1>Zarządzanie bezpieczeństwem aplikacji</h1>\n",
|
||||
"<h2>9. <i>Projekt badawczo-rozwojowy</i> [wykład]</h2> \n",
|
||||
"<h3>Tomasz Kowalski (2022)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "medium-jamaica",
|
||||
"metadata": {
|
||||
"slideshow": {
|
||||
"slide_type": "slide"
|
||||
}
|
||||
},
|
||||
"source": [
|
||||
"## Infrastruktura krytyczna\n",
|
||||
"\n",
|
||||
"> (...) to rzeczywiste i cybernetyczne systemy (obiekty, urządzenia bądź instalacje) niezbędne do minimalnego funkcjonowania gospodarki i państwa. [(źródło: RCB)](https://www.gov.pl/web/rcb/infrastruktura-krytyczna)\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"1. Energia (prąd elektryczny, paliwo)\n",
|
||||
"2. Łączność (telefon, internet)\n",
|
||||
"3. Finanse (karta płatniczna, bankowość elektroniczna)\n",
|
||||
"4. Żywność\n",
|
||||
"5. Woda\n",
|
||||
"\n",
|
||||
"oraz wiele innych składników tzw. [infrastruktury krytycznej](https://www.gov.pl/web/rcb/systemy-infrastruktury-krytycznej) to są Twoje zależności (ang. dependencies)\n",
|
||||
"\n",
|
||||
"Infrastruktura krytyczna to, według ustawy o zarządzaniu kryzysowym, systemy oraz wchodzące w ich skład powiązane ze sobą funkcjonalnie obiekty, w tym obiekty budowlane, urządzenia, instalacje, usługi kluczowe dla bezpieczeństwa państwa i jego obywateli oraz służące zapewnieniu sprawnego funkcjonowania administracji publicznej, a także instytucji i przedsiębiorców."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "indonesian-miracle",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div id=\"zadanie1_wyklad\" class=\"alert alert-block alert-info\">\n",
|
||||
" Teraz warto zrealizować <a href=\"#zadanie1\">zadanie 1</a>.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "german-aberdeen",
|
||||
"metadata": {
|
||||
"slideshow": {
|
||||
"slide_type": "slide"
|
||||
}
|
||||
},
|
||||
"source": [
|
||||
"<a id=\"typowy_stos_aplikacyjny\"></a>\n",
|
||||
"## Typowy stos aplikacyjny\n",
|
||||
" \n",
|
||||
"1. Aplikacja\n",
|
||||
"2. Middleware\n",
|
||||
"3. Userspace\n",
|
||||
"4. Kernel\n",
|
||||
"5. Bootloader\n",
|
||||
"6. Hypervisor\n",
|
||||
"7. Firmware\n",
|
||||
"8. BIOS | EFI\n",
|
||||
"9. CPU | Management Engine\n",
|
||||
"\n",
|
||||
"Czy masz świadomość zależności Twojej aplikacji na drugiej i kolejnych warstwach?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "hollow-reliance",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div id=\"zadanie2_wyklad\" class=\"alert alert-block alert-info\">\n",
|
||||
" Teraz warto zrealizować <a href=\"#zadanie2\">zadanie 2</a>.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "killing-stroke",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div id=\"zadanie3_wyklad\" class=\"alert alert-block alert-info\">\n",
|
||||
" Teraz warto zrealizować także <a href=\"#zadanie3\">zadanie 3</a>.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "super-shooting",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Jakie są współczesne aplikacje?\n",
|
||||
"\n",
|
||||
"### Fikcyjny stos, ale (niestety) ze znajomymi elementami\n",
|
||||
"\n",
|
||||
"Humor (w różnych postaciach) jest tym środkiem, z użyciem którego wyraża się prawdy, które wypowiedziane wprost byłby trudne do przyjęcia.\n",
|
||||
"\n",
|
||||
"Popatrzmy na [XKCD 1636](https://xkcd.com/1636).\n",
|
||||
"\n",
|
||||
"Jeśli odniesienia obecne w tej grafice nie są czytelne to można [podeprzeć się objaśnieniem](https://www.explainxkcd.com/wiki/index.php/1636:_XKCD_Stack).\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-warning\">\n",
|
||||
"<b>Do przemyślenia.</b> Być może pracujesz przy młodym projekcie lub produkcie i jego konstrukcja jest czytelna, a każdy element ma opiekuna. Jednak jeśli pracujesz przy produkcie, który ma już pewną historię, to czy dostrzegasz w nim miejsca, które zrealizowane są w nieoczywisty lub przestarzały sposób? Jeśli tak to jest w zespole ktoś kto opiekuje się tym elementem? (A może autorzy tego rozwiązania już przy tym produkcie nie pracują i nikt nie przejął opieki na tym elementem?)\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"### Rzeczywisty \"stos\" - przkład: linux w przeglądarce\n",
|
||||
"\n",
|
||||
"Niestety żart w informatyce potrafi przerodzić się w rzeczywistość.\n",
|
||||
"\n",
|
||||
"Już [w 2011 kernel linuksowy pracował wewnątrz przeglądarki](https://www.theregister.com/2011/05/18/javascript_pc_emulator/). Tylko dlaczego?! (Po co?)\n",
|
||||
"\n",
|
||||
"Jest [2022 i temat nadal jest aktualny.](https://hackaday.com/2022/05/28/linux-and-c-in-the-browser/)\n",
|
||||
"\n",
|
||||
"Mało tego - rzecz zdaje się eskalować, gdyż w [ramach emulacji można już uruchomić kompletny system](https://bellard.org/jslinux/), a samo [jądro przeportowano i pracuje w przeglądarce natywnie.](https://retrage.github.io/lkl-js/)\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-warning\">\n",
|
||||
"<b>Do przemyślenia.</b> Niegdyś napisanie aplikacji desktopowej w ten sposób, że jest to tzw. webówka działająca na localhost w zakamuflowanej przeglądarce (bez paska narzędzi, bez paska adresu, itp.) wydawało się żartem, a dziś [Electron](https://www.electronjs.org/) (i podobne frameworki) nikogo nie dziwią (a użytkownicy Atom, GitHub Desktop, Light Table, Visual Studio Code, WordPress Desktop czy Eclipse Theia, często nie wiedzę jak one są skonstruowane). \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "lyric-treasure",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Jak radzimy sobie z utrzymaniem i rozwojem oprogramowania w dłuższej perspektywie?\n",
|
||||
"\n",
|
||||
"Humorystyczne, ale prawdziwie, ujmuje to [Geek&Poke 2011/3/1](https://geek-and-poke.com/geekandpoke/2011/3/1/architectural-best-practices.html)\n",
|
||||
"\n",
|
||||
"Rzeczywistość, w której stare i słabe komponenty próbuje się \"maskować\", dobrze przedstawia historia [Synactive na pwn2own 2021](https://www.synacktiv.com/en/publications/the-printer-goes-brrrrr.html).\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-danger\">\n",
|
||||
" <b>Uwaga do zapamiętania.</b> To już jest <b>zarządzanie bezpieczeństwem</b> jednak w wariancie, który trudno z czystym sumieniem polecić. \n",
|
||||
"\n",
|
||||
"Można zrozumieć, że są pewne zależności, których niesposób zmienić (z powodu kosztów, skali problemu, itp.) jednak ogólnie obfuskacją nie można przykryć niedomagań systemu operacyjnego pozbawionego współczesnych środków bezpieczeństwa.\n",
|
||||
" \n",
|
||||
" Zamaskowania problemu to zwykle (a w dłuższej perspektywie - zawsze) zły pomysł.\n",
|
||||
"</div>\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "allied-anxiety",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zapobieganie powstawaniu błędów\n",
|
||||
"\n",
|
||||
"### Dla ops-ów mamy\n",
|
||||
"\n",
|
||||
"[CIS Microsoft Windows 11 Enterprise Benchmark](https://www.cisecurity.org/benchmark/microsoft_windows_desktop)\n",
|
||||
"\n",
|
||||
"[CIS Distribution Independent Linux Benchmark](https://www.cisecurity.org/benchmark/distribution_independent_linux)\n",
|
||||
"\n",
|
||||
"i wiele wiele innych\n",
|
||||
"\n",
|
||||
"### Dla dev-ów mamy\n",
|
||||
"\n",
|
||||
"[OWASP Secure Coding Practices](https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf)\n",
|
||||
"\n",
|
||||
"[SEI Secure Coding Standards](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards)\n",
|
||||
"\n",
|
||||
"[BDEW Whitepaper Requirements for Secure Control and Telecommunication Systems](https://www.bdew.de/media/documents/Awh_20180507_OE-BDEW-Whitepaper-Secure-Systems-engl.pdf)\n",
|
||||
"\n",
|
||||
"[CIS Application Software Security](https://www.cisecurity.org/controls/application-software-security)\n",
|
||||
"\n",
|
||||
"[CIS Software Supply Chain](https://www.cisecurity.org/insights/white-papers/cis-software-supply-chain-security-guide)\n",
|
||||
"\n",
|
||||
"ale także\n",
|
||||
"\n",
|
||||
"[ISO 27002](https://www.iso.org/standard/75652.html)\n",
|
||||
"\n",
|
||||
"[ISO 27019](https://www.iso.org/standard/68091.html)\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<b>Literatura.</b> Powyższe pozycje należy traktować jak wskazanie dalszej lektury po tym wykładzie. Jeśli same dokumenty źródłowe okażą się niewystarczające to posługując się ich nazwami można wyszukać wtórne opracowania.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "rocky-democrat",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Przykład: OWASP SCP Quick Reference Guide\n",
|
||||
"\n",
|
||||
"(link był wcześniej: Zapobieganie powstawaniu błędów -> Dla dev-ów)\n",
|
||||
"\n",
|
||||
"Obecnie v2\n",
|
||||
"\n",
|
||||
"11.2010 (niby stare, ale wątpię czy cokolwiek z tego można spokojnie pominąć)\n",
|
||||
"\n",
|
||||
"PDF ma zaledwie 17 stron:\n",
|
||||
"* checklist-a dobrych praktyk (str. 5-13)\n",
|
||||
" * walidacja wejścia\n",
|
||||
" * encoding wyjścia\n",
|
||||
" * autentykacja i zarządzanie hasłami\n",
|
||||
" * zarządzanie sesją\n",
|
||||
" * kontrola dostępu\n",
|
||||
" * praktyki kryptograficzne\n",
|
||||
" * obsługa błędów i logowania\n",
|
||||
" * ochrona danych\n",
|
||||
" * bezpieczeństwo komunikacji\n",
|
||||
" * konfiguracja systemu\n",
|
||||
" * bezpieczeństwo związane z obsługą bazy danych\n",
|
||||
" * zarządzanie plikami\n",
|
||||
" * zarządzanie pamięcią\n",
|
||||
" * ogólnie, praktyki programistyczne\n",
|
||||
"* elementarny słownik pojęć związanych z bezpieczeństwem (str. 15-17)\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "educated-sperm",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div id=\"zadanie4_wyklad\" class=\"alert alert-block alert-info\">\n",
|
||||
" Teraz warto zrealizować <a href=\"#zadanie4\">zadanie 4</a>.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "vocal-stanley",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Stos zagrożeń (~ISO OSI RM)\n",
|
||||
"\n",
|
||||
"Każdy słyszał o modelu referencyjnym ISO OSI, ale o tym, że można go zamapować na stos tzw. thread actors, już nie każdy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "cheap-information",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div id=\"zadanie5_wyklad\" class=\"alert alert-block alert-info\">\n",
|
||||
" Teraz warto zrealizować <a href=\"#zadanie5\">zadanie 5</a>.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "tight-nightlife",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Kwestia tzw. credentials\n",
|
||||
"\n",
|
||||
"Czyli API keys, username/passwd, certificates, … \n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-warning\">\n",
|
||||
"<b>Do przemyślenia.</b> \n",
|
||||
"Gdzie są “credentials” do tych wszystkich systemów i usług, które wykorzystujecie w projekcie lub produkcie?\n",
|
||||
"<ul>\n",
|
||||
"<li> Kto ma do nich dostęp?\n",
|
||||
"<li> Jak je otrzymali?\n",
|
||||
"<li> Gdzie są przechowywane?\n",
|
||||
"<li> Gdzie są używane?\n",
|
||||
"</ul>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"Drogi Programisto, czy jest coś cenniejszego niż kod źródłowy? Kod jest czymś co lub wyciekać, a to przecież cały majątek Twojej firmy.\n",
|
||||
"\n",
|
||||
"Problem wyciekania kodu i różnego rodzaju \"credentials\" jest tak duży, że doczekał się własnego określenia - jest to tzw. \"secret sprawl\". Szczegóły np. [w tegorocznym w raporcie Gitguardian](https://www.gitguardian.com/state-of-secrets-sprawl-report-2022)\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<b>Literatura.</b> Powyższa pozycja to wskazanie dalszej lektury po tym wykładzie. \n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-warning\">\n",
|
||||
"<b>Do przemyślenia.</b> Czy wśród zależności Twojego projektu lub produktu znalazł się używany przez Ciebie VSC? Jak go chronisz? \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "lined-checkout",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Jak poznać czy jest dobrze czy już źle?\n",
|
||||
"\n",
|
||||
"Pasażerowie płonącego samolotu potrafią [zachować się jakby nic nietypowego się nie wydarzyło.](https://www.youtube.com/watch?v=1-6APD-pXe0) A jak Ty poznasz, że coś poszło nie tak?\n",
|
||||
"\n",
|
||||
"[Użyj kanarka!](https://docs.canarytokens.org/guide/)\n",
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<b>Literatura.</b> Powyższa pozycja to wskazanie dalszej lektury po tym wykładzie. \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "floppy-junction",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div id=\"zadanie6_wyklad\" class=\"alert alert-block alert-info\">\n",
|
||||
" Teraz warto zrealizować <a href=\"#zadanie5\">zadanie 6</a>.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "nuclear-thesaurus",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zabezpieczenie linii produkcyjnej oprogramowania i łańcucha dostaw\n",
|
||||
"\n",
|
||||
"Usterki w zakresie bezpieczeństwa mogą pojawić się na każdym etapie rozwoju oprogramowania:\n",
|
||||
"* (już na starcie) nie zidentyfikowano wymagań dot. bezpieczeństwa\n",
|
||||
"* stworzono projekt (ang. design), który ma błędy logiczne\n",
|
||||
"* kiepska kultura kodowania poskutkowała wadami technicznymi (a więc podatnościami)\n",
|
||||
"* wdrożenie (ang. deployment) było … niewłaściwe\n",
|
||||
"* (na koniec, a więc ang. maintenance) zaktualizowano o nowe błędy \n",
|
||||
"\n",
|
||||
"### Zapobieganie? Np. CIS Software Supply Chain Security Guide\n",
|
||||
"\n",
|
||||
"[obecnie v1](https://www.cisecurity.org/insights/white-papers/cis-software-supply-chain-security-guide)\n",
|
||||
"\n",
|
||||
"świeżynka (10/2022)\n",
|
||||
"\n",
|
||||
"PDF ma 66 stron, 100+ rekomendacji: \n",
|
||||
"* Kod źródłowy\n",
|
||||
" * zmiany w kodzie\n",
|
||||
" * zarządzanie repozytorium\n",
|
||||
" * uprawnienia do modyfikacji kodu\n",
|
||||
" * dostęp dla stron trzecich\n",
|
||||
" * ryzyka związane z kodem\n",
|
||||
"* Build pipelines\n",
|
||||
" * środowisko\n",
|
||||
" * worker\n",
|
||||
" * budowa pipeline\n",
|
||||
" * integralność pipeline\n",
|
||||
"* Zależności\n",
|
||||
" * pakiety stron trzecich\n",
|
||||
" * walidacja pakietów\n",
|
||||
"* Artefakty\n",
|
||||
" * weryfikacja\n",
|
||||
" * dostęp do nich\n",
|
||||
" * ich repo\n",
|
||||
" * śledzenie pochodzenia\n",
|
||||
"* Wdrożenie\n",
|
||||
" * środowisko\n",
|
||||
" * konfiguracja"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "metallic-patrick",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Podsumowanie\n",
|
||||
"\n",
|
||||
"To nie ludzie z operations kształtują bezpieczeństwo. To <b>jakość pracy programisty wyznacza jego poziom</b>.\n",
|
||||
"\n",
|
||||
"Zarządzanie bezpieczeństwem polega na tym, aby właściwym ludziom \"się chciało\".\n",
|
||||
"\n",
|
||||
"Zarządzanie bezpieczeństwem coś jakby BHP (fabryka dla niepoznaki zwana jest software house).\n",
|
||||
"\n",
|
||||
"Zarządzanie bezpieczeństwem polega na podejmowaniu trudnych decyzji (czas, pieniądze, itp.), które wpływają na kształt projektu, wartość produktu i odciskają piętno na jakości życia użytkowników.\n",
|
||||
"\n",
|
||||
"Powoli zmierzamy w stronę standaryzacji np. Supply-chain Levels for Software Artifacts (SLSA) lub The Update\n",
|
||||
"Framework (TUF).\n",
|
||||
"\n",
|
||||
"<b>Ludzie z operations nie zarządzają bezpieczeństwem</b>. Ponieważ produkty są takie jakimi wypuścili je programiści to w operations mamy już tylko \"vulnerability management\"."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "connected-picnic",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Propozycje zadań na laboratorium\n",
|
||||
"\n",
|
||||
"<a id=\"zadanie1\"></a>\n",
|
||||
"## Zadanie 1. Od czego zależy Twoja aplikacja lub projekt?\n",
|
||||
"\n",
|
||||
"Przypomnij sobie którykolwiek ze swoich projektów. Co jest niezbędne dla jego prawidłowego funkcjonowania? \n",
|
||||
"(Także w dłuższej perspektywie czasowej).\n",
|
||||
"\n",
|
||||
"Podaj nazwy. (Np. biblioteki, systemu, usługi, narzędzia, sprzętu, …)\n",
|
||||
"\n",
|
||||
"[Kliknij aby wrócić do właściwego miejsca w wykładzie](#zadanie1_wyklad)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "extended-switzerland",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<a id=\"zadanie2\"></a>\n",
|
||||
"## Zadanie 2. Od czego w nieoczywisty sposób zależy Twoja aplikacja lub projekt?\n",
|
||||
"\n",
|
||||
"Przyjrzyj się projektowi lub produktowi nad którym pracujesz. Spójrz na [\"typowy stos aplikacyjny\"](#typowy_stos_aplikacyjny) i dla każdej z warstw (drugiej warstwy i kolejnych) wskaż właściwy projekt lub produkt. To też są Twoje zależności."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "native-private",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<a id=\"zadanie3\"></a>\n",
|
||||
"## Zadanie 3. Jak dojrzałe są Twoje zależności?\n",
|
||||
"\n",
|
||||
"Dla każdego projektu lub produktu zidentyfikowanego w poprzednim zadaniu 2 odszukaj informację o choć jednej podatności (ang. vulnerability).\n",
|
||||
"\n",
|
||||
"Informacja o jak najmłodszych podatnościach jest najcenniejsza. Czy Ty lub Twój zespół podjęliście już właściwe środki zaradcze?\n",
|
||||
"\n",
|
||||
"Informacja o starszych podatnościach również jest wartościowa. Skąd wiesz, że te problemy już nie występują? Co jest źródłem tej pewności? Co sądzisz o jakości tego projektu lub produktu patrząc na ilość i typ zidentyfikowanych podatności?\n",
|
||||
"\n",
|
||||
"[Kliknij aby wrócić do właściwego miejsca w wykładzie](#zadanie3_wyklad)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "dental-portfolio",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<a id=\"zadanie4\"></a>\n",
|
||||
"\n",
|
||||
"## Zadanie 4. Zgodność z zaleceniami OWASP.\n",
|
||||
"\n",
|
||||
"W zespole - przyłóżcie tych 214 zaleceń OWASP do swojego projektu; ile z nich już spełniacie?\n",
|
||||
"\n",
|
||||
"[Kliknij aby wrócić do właściwego miejsca w wykładzie](#zadanie4_wyklad)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "changed-helena",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<a id=\"zadanie5\"></a>\n",
|
||||
"## Zadanie 5\n",
|
||||
"\n",
|
||||
"Przyjrzyj się [XKCD 2166](https://xkcd.com/2166) i dla każdej z warstw na tym stosie odszukaj informacje o choćby jednej:\n",
|
||||
"* zidentyfikowanej podatności tego typu \n",
|
||||
"* lub doniesienia prasowe np. o głośnych incydentach w tym zakresie.\n",
|
||||
"\n",
|
||||
"Jeśli w przypadku niższych warstw nie wiesz gdzie zacząć to zerknij na [objaśnienie do komiksu.](https://www.explainxkcd.com/wiki/index.php/2166:_Stack)\n",
|
||||
"\n",
|
||||
"[Kliknij aby wrócić do właściwego miejsca w wykładzie](#zadanie5_wyklad)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"id": "mysterious-baseline",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<a id=\"zadanie6\"></a>\n",
|
||||
"## Zadanie 6\n",
|
||||
"\n",
|
||||
"Utwórz na Github publiczne repo.\n",
|
||||
"Stwórz w nim “fejkowy” projekt - trochę kodu, jakiś config.\n",
|
||||
"\n",
|
||||
"[Wygeneruj kanarka](https://docs.canarytokens.org/guide/) - klucz AWS.\n",
|
||||
"Dopisz go w configu, zacommituj, pchnij.\n",
|
||||
"\n",
|
||||
"Zjedz kanapkę, wypij kawę, … a po chwili z przerażeniem obserwuj co by to było, gdyby to był faktyczny klucz.\n",
|
||||
"\n",
|
||||
"[Kliknij aby wrócić do właściwego miejsca w wykładzie](#zadanie6_wyklad)"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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.10"
|
||||
}
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 5
|
||||
}
|
||||
334
10_wybrane_zagadnienia_testowania.ipynb
Normal file
334
10_wybrane_zagadnienia_testowania.ipynb
Normal file
@ -0,0 +1,334 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "lJs0WcXzpfho"
|
||||
},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 10. <i>Wybrane zagadnienia testowania</i>[wykład]</h2> \n",
|
||||
"<h3>Rafał Jaworski (2023)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan wykładu\n",
|
||||
"\n",
|
||||
"1. Dlaczego warto testować?\n",
|
||||
"1. Określenie pojęcia testowania.\n",
|
||||
"1. Typy testowania.\n",
|
||||
"1. Planowanie testów.\n",
|
||||
"1. Testowanie automatyczne "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Dlaczego warto testować?\n",
|
||||
"*(źródło: https://udigroup.pl/blog/testowanie-oprogramowania-typy-rodzaje-poziomy/#co-to-testowanie-oprogramowania)*\n",
|
||||
"\n",
|
||||
"### Nissan\n",
|
||||
"W samochodach Nissana wykryto awarię oprogramowania w czujnikach poduszek powietrznych. Zgłoszono dwa wypadki, które spowodowane były tą wadą. W związku z tym niedopatrzeniem, firma musiała wycofać ponad milion aut z rynku.\n",
|
||||
"\n",
|
||||
"### Starbucks\n",
|
||||
"Starbucks napotkał awarię oprogramowania w swoim systemie POS (Point of Sale – narzędzie do przyjmowania i obsługi zamówień). Ze względu na brak możliwości przetworzenia transakcji, kawiarnia wydawała klientom kawę za darmo i musiała zamknąć ok. 60% swoich placówek w Kanadzie i USA.\n",
|
||||
"\n",
|
||||
"### Yahoo!\n",
|
||||
"W 2016 r. Yahoo! ujawnił, że padł ofiarą jednego z największych w historii wycieków danych, który dotyczył ponad 3,5 miliardów kont użytkowników. Firma stała się przez to podmiotem wielkiej krytyki za niedopatrzenia w zakresie bezpieczeństwa. Ponadto musiała zmierzyć się z kilkoma procesami sądowymi, a jej wartość w transakcji przejęcia przez Verizon Communications spadła o 350 milionów dolarów.\n",
|
||||
"\n",
|
||||
"### China Airlines\n",
|
||||
"26 kwietnia 1994 r. samolot China Airlines rozbił się w Japonii podczas podejścia do lądowania. Z powodu błędu oprogramowania, w katastrofie śmierć poniosły 264 osoby, a 7 w stanie ciężkim trafiło do szpitala.\n",
|
||||
"\n",
|
||||
"### Morele.net\n",
|
||||
"W 2018 roku doszło do wycieku danych ponad 2 milionów użytkowników sklepu internetowego Morele. UODO nałożyło na firmę rekordową karę 2,8 milionów złotych za brak właściwych zabezpieczeń sklepu przed atakiem hakerów.\n",
|
||||
"\n",
|
||||
"### First National Bank of Chicago\n",
|
||||
"W 1996 r. w dużym banku amerykańskim wystąpił błąd oprogramowania. W wyniku tego na konta ponad 800 klientów wpłynęło po 920 mln dolarów amerykańskich."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "LGcbq5Wmpfhy"
|
||||
},
|
||||
"source": [
|
||||
"# 2. Podstawowe definicje"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "L6Of2X4kpfhy"
|
||||
},
|
||||
"source": [
|
||||
" - ***Testowanie** to poddawanie czegoś próbie z oczekiwaniem na **konkretny wynik***\n",
|
||||
" - ***Testowanie** to proces składający się ze wszystkich czynności cyklu życia, zarówno statycznych, jak i dynamicznych, skoncentrowany na planowaniu, przygotowaniu i ewaluacji oprogramowania oraz powiązanych produktów w celu określenia, czy spełniają one **wyspecyfikowane wymagania**, na wykazaniu, że są one dopasowane do swoich celów oraz na wykrywaniu usterek*\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" - **Błąd (error)** to objaw nieoczekiwanego działania programu ujawniony podczas testów.\n",
|
||||
" - **Defekt (fault)** to niedoskonałość w kodzie programu. \n",
|
||||
"\n",
|
||||
"Błąd ujawniony w czasie testów świadczy o <i>defekcie</i> w testowanym kodzie.\n",
|
||||
" "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Typy testowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Podział testów - ze względu na dostępność kodu źródłowego"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" - **testy białej skrzynki** - tester ma pełny dostęp do kodu źródłowego\n",
|
||||
" - **testy czarnej skrzynki** - tester nie ma dostępu do kodu źródłowego\n",
|
||||
" - **testy szarej skrzynki** - tester ma ograniczony dostęp do kodu źródłowego\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2 Podział testów - ze względu na zakres testowanego systemu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"- **modułowe** - testowana jest jedna klasa lub niewielki pakiet klas (np. jUnit),\n",
|
||||
"- **integracyjne wewnętrzne** - testowanych jest wspólnie kilka modułów,\n",
|
||||
"- **systemowe** - testowany jest cały system ze wszystkimi funkcjonalnościami,\n",
|
||||
"- **integracyjne zewnętrzne** - testowana jest współpraca systemu z innymi systemami.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.3. Podział testów - ze względu na przedmiot testowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy funkcjonalne\n",
|
||||
"Testy funkcjonalności systemu na podstawie przypadków testowych.\n",
|
||||
"\n",
|
||||
"### Testy niefunkcjonalne\n",
|
||||
"\n",
|
||||
"- **Testy wydajnościowe** - testy szybkości działania wybranych funkcji systemu.\n",
|
||||
"- **Testy przeciążeniowe** - testy systemu w warunkach wysokiego obciążenia (znaczna liczba jednoczesnych użytkowników).\n",
|
||||
"- **Testy pamięciowe** - testy zużycia pamięci.\n",
|
||||
"- **Testy ochrony danych** - zapewnienie bezpieczeństwa danych przed wyciekiem.\n",
|
||||
"- **Testy konfiguracji** - testowanie działania systemu uruchamianego w różnych konfiguracjach (np. na różnych systemach operacyjnych).\n",
|
||||
"- **Testy zgodności wersji** - testowanie zgodności aplikacji z jej poprzednimi wersjami.\n",
|
||||
"- **Testowanie zgodności z instrukcją użytkownika** - testom jest w zasadzie poddawana instrukcja.\n",
|
||||
"- **Testowanie procedury instalacyjnej** - testowanie procedury instalacji systemu w czystym środowisku."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.4. Podział testów - ze względu na fazę testowania\n",
|
||||
"- **Testy dymne (smoke tests)** - powierzchowne testy sprawdzające tylko podstawowe funkcje aplikacji\n",
|
||||
"- **Testy zdroworozsądkowe (sanity tests)** - testy sprawdzające, czy aplikacja lub jej konkretna funkcjonalność działają zgodnie z podstawowymi założeniami\n",
|
||||
"- **Testy akceptacyjne** - sprawdzenie kompletności systemu i jego prawidłowego działania\n",
|
||||
"- **Testy regresywne** - sprawdzenie, czy naprawa błędów nie wprowadziła nowych błędów."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Plan testów\n",
|
||||
"**Plan testów** to dokument opisujący organizację procesu testowania. \n",
|
||||
" * Dotyczy zazwyczaj testowania systemowego.\n",
|
||||
" * Plan testów składa się z następujących elementów:\n",
|
||||
" * Zakres testów\n",
|
||||
" * Strategia testowania\n",
|
||||
" * Zasoby niezbędne do testów\n",
|
||||
" * Specyfikacja testów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.1. Zakres testów\n",
|
||||
" * Identyfikacja testowanego produktu (co testujemy?)\n",
|
||||
" * Określenie wymagań (właściwości), które testujemy\n",
|
||||
" * Określenie wymagań (właściwości), których nie testujemy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.2. Metodologia testowania\n",
|
||||
" * Określenie typów testowania, które przeprowadzimy.\n",
|
||||
" * Określenie typów testowania, których nie przeprowadzimy.\n",
|
||||
" * Zdefiniowanie metod oceny testu\n",
|
||||
" * Zdefiniowanie typów błędów (awarie, błędy istotne, błędy nieistotne)\n",
|
||||
" * Określenie kryteriów pozytywnego zakończenia testów\n",
|
||||
" * Przykładowo: określenie dopuszczalnej liczby błędów poszczególnego typu\n",
|
||||
" * Określenie postaci raportu z testów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.3. Zasoby niezbędne do testów\n",
|
||||
" * Środowisko testowe\n",
|
||||
" * Oprogramowanie zastosowane w testowaniu\n",
|
||||
" * Zespół wykonawców\n",
|
||||
" * Warunki początkowe, np.:\n",
|
||||
" * np. wykonane prace instalacyjne lub konfiguracyjne\n",
|
||||
" * stopień ukończenia prac implementacyjnych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.4. Specyfikacja testów \n",
|
||||
"**Specyfikacja testów** to zestaw scenariuszy testowych (przypadków testowych)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Testowanie automatyczne\n",
|
||||
"**Automatyzacja testowania** polega na zastąpienia testera oprogramowaniem, które:\n",
|
||||
"* Steruje testem,\n",
|
||||
"* Porównuje wyniki z oczekiwaniami,\n",
|
||||
"* Raportuje błędy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.1. Podejścia do testowania automatycznego\n",
|
||||
"\n",
|
||||
"### Code-driven testing (testowanie sterowane kodem)\n",
|
||||
" * Testowane są publiczne interfejsy do klas (modułów, bibliotek) poprzez podanie różnorakich danych wejściowych i walidacji wyników.\n",
|
||||
" * Jest to poziom testów jednostkowych.\n",
|
||||
"\n",
|
||||
"### Graphical user interface testing (testowanie graficznego interfejsu użytkownika)\n",
|
||||
" * Generowane są zdarzenia interfejsu takie jak: kliknięcia myszką czy naciśnięcie klawiszy i obserwowane są zmiany w interfejsie użytkownika. \n",
|
||||
" * Jest to poziom testów systemowych.\n",
|
||||
" \n",
|
||||
"#### Testowanie za pomocą makr, np. Macro Express (https://www.macros.com/)\n",
|
||||
"1. Nagrywamy makro realizujące ciąg zdarzeń (kliknięć, klawiszy itp.),\n",
|
||||
"2. przygotowujemy zestaw plików graficznych, które obrazują kolejne oczekiwane wyglądy interfejsu,\n",
|
||||
"3. podczas testowania każdorazowo porównujemy obrazy interfejsu z obrazami oczekiwanymi.\n",
|
||||
"\n",
|
||||
"#### Testowanie za pomocą oprogramowania, np. Selenium\n",
|
||||
"(http://tynecki.pl/pdf/Automating-functional-tests-using-Python-and-Selenium-Piotr-Tynecki.pdf)\n",
|
||||
"* Opracowujemy sekwencję zdarzeń (kliknięć, klawiszy itp.).\n",
|
||||
"* Sprawdzamy powodzenie testowanej operacji (np. sprawdzamy, czy istnieje na stronie poszukiwany element).\n",
|
||||
"\n",
|
||||
"#### Zalety automatycznego testowania GUI\n",
|
||||
"* Może być stosowane do każdego oprogramowania z graficznym interfejsem użytkownika.\n",
|
||||
"* Znakomicie wkomponowuje się w paradygmat „continous integration”.\n",
|
||||
"\n",
|
||||
"#### Wady automatycznego testowania GUI\n",
|
||||
"* Przygotowanie przypadków testowych jest czasochłonne.\n",
|
||||
"* Każda najmniejsza zmiana interfejsu powoduje konieczność opracowania nowego zestawu testowego.\n",
|
||||
"* W scenariuszach zawarte są często operacje nieistotne z punktu widzenia testowania."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Bibliografia\n",
|
||||
"\n",
|
||||
"1. \"Testowanie oprogramowania – poznaj świat testów\", Ilona Kusztykiewicz https://www.jcommerce.pl/jpro/artykuly/testowanie-oprogramowania\n",
|
||||
"1. \"Testowanie niezbędnym elementem tworzenia oprogramowania. Jakie są jego typy, rodzaje i poziomy?\", Aleksandra Skalska, https://udigroup.pl/blog/testowanie-oprogramowania-typy-rodzaje-poziomy/#co-to-testowanie-oprogramowania\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {
|
||||
"id": "DBJy5KNHpfh4"
|
||||
},
|
||||
"source": [
|
||||
"## Zadania (proponowane do realizacji na laboratoriach)\n",
|
||||
"\n",
|
||||
"### Zadanie 1. Dyskusja nad odpowiednim sposobem testowania\n",
|
||||
"Przeprowadźcie dyskusję nad odpowiednim sposobem testowania, który będzie najbardziej odpowiedni dla Waszego projektu. Sporządźcie raport z dyskusji, w którym zawarte będą wady i zalety proponowanych metod.\n",
|
||||
"\n",
|
||||
"### Zadanie 2. Plan testowania\n",
|
||||
"\n",
|
||||
"Sporządźcie realny plan testowania Waszej aplikacji. Określcie metodykę testowania, osoby testujące (dobrze byłoby mieć testerów spoza zespołu projektowego, proszę się wymieniać), kryteria akceptacji projektu oraz obieg pracy związany ze zgłaszaniem i naprawą błędów.\n",
|
||||
"\n",
|
||||
"### Zadanie 3. Scenariusze testowe\n",
|
||||
"\n",
|
||||
"Sporządźcie szczegółowe scenariusze testowe dla wybranych najważniejszych funkcjonalności Waszego projektu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Rafał Jaworski",
|
||||
"colab": {
|
||||
"provenance": []
|
||||
},
|
||||
"email": "rjawor@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3 (ipykernel)",
|
||||
"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.10.6"
|
||||
},
|
||||
"org": null,
|
||||
"subtitle": "10. Wybrane zagadnienia testowania",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2022"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -155,7 +155,7 @@
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.9.12"
|
||||
"version": "3.10.8"
|
||||
}
|
||||
},
|
||||
"nbformat": 4,
|
||||
|
||||
BIN
obrazy/07_prince_poziomy_zarzadzania.jpg
Normal file
BIN
obrazy/07_prince_poziomy_zarzadzania.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 84 KiB |
BIN
obrazy/07_prince_strukt_organizac_projektu.jpg
Normal file
BIN
obrazy/07_prince_strukt_organizac_projektu.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 135 KiB |
BIN
obrazy/07_prince_tematy.jpg
Normal file
BIN
obrazy/07_prince_tematy.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 130 KiB |
BIN
obrazy/cd.drawio.png
Normal file
BIN
obrazy/cd.drawio.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
BIN
obrazy/ci.drawio.png
Normal file
BIN
obrazy/ci.drawio.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
BIN
obrazy/gonito-platform.png
Normal file
BIN
obrazy/gonito-platform.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
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/meta-eval.png
Normal file
BIN
obrazy/meta-eval.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 126 KiB |
BIN
obrazy/mlops.drawio.png
Normal file
BIN
obrazy/mlops.drawio.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 107 KiB |
BIN
obrazy/mlops2.drawio.png
Normal file
BIN
obrazy/mlops2.drawio.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 136 KiB |
BIN
obrazy/seul-metro.png
Normal file
BIN
obrazy/seul-metro.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
BIN
obrazy/testing.jpg
Normal file
BIN
obrazy/testing.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 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 |
BIN
obrazy/utility.jpg
Normal file
BIN
obrazy/utility.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Loading…
Reference in New Issue
Block a user