From 6ccd39bced0ccce2de3e572210a9506918a61b4e Mon Sep 17 00:00:00 2001 From: Robert Bendun Date: Sun, 28 Jan 2024 19:27:53 +0100 Subject: [PATCH] Analiza ryzyka --- analiza-ryzyka.adoc | 171 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 analiza-ryzyka.adoc diff --git a/analiza-ryzyka.adoc b/analiza-ryzyka.adoc new file mode 100644 index 0000000..72018c8 --- /dev/null +++ b/analiza-ryzyka.adoc @@ -0,0 +1,171 @@ += KPI (kryteria sukcesu) i analiza ryzyka +:toc: +:author: Robert Bendun +:email: robben@st.amu.edu.pl +:revnumber: 1.0.0 +:revdate: 2024-01-27 +:nofooter: +// Polish translation, courtesy of Łukasz Dziedziul with updates via Matthew Blissett +:appendix-caption: Dodatek +:appendix-refsig: {appendix-caption} +:caution-caption: Uwaga +:chapter-signifier: Rozdział +:chapter-refsig: {chapter-signifier} +:example-caption: Przykład +:figure-caption: Rysunek +:important-caption: Ważne +:last-update-label: Ostatnio zmodyfikowany +ifdef::listing-caption[:listing-caption: Listing] +ifdef::manname-title[:manname-title: Nazwa] +:note-caption: Notka +:part-signifier: Część +:part-refsig: {part-signifier} +ifdef::preface-title[:preface-title: Wstęp] +:section-refsig: Sekcja +:table-caption: Tabela +:tip-caption: Sugestia +:toc-title: Spis treści +:untitled-label: Bez tytułu +:version-label: Wersja +:warning-caption: Ostrzeżenie +:sectanchors: +:pdf-theme: theme.yml + +== Historia wersji + +[cols="1,2,3,2"] +|=== +| Osoba | Data | Zmiany | Wersja + +| Robert Bendun | 2024-01-27 | Stworzenie dokumentu | 1.0.0 +|=== + +Stosowane jest https://semver.org/lang/pl/[wersjonowanie semantyczne] oraz format dat https://en.wikipedia.org/wiki/ISO_8601[ISO 8601]. + +== Analiza ryzyka + +Przyjętą metodologią oceny ryzyk i ich wpływów jest opisana w ramach wykładu https://uam.sharepoint.com/:b:/r/sites/2023SZ06-DPPBUI0WYKPrzygotowaniedoprojektubadawczo-rozwojowe/Materiay%20z%20zaj/Wyk%C5%82ad%2008%20Zarz%C4%85dzanie%20ryzykiem.pdf?csf=1&web=1&e=jFX6nL["Zarządzanie ryzykiem w projekcie informatycznym"] prof. Jacka Marciniaka przedstawionym w ramach przedmiotu "Przygotowanie do projektu badawczo-rozwojowego". + +=== Główne ryzyka projektu + +Podrozdział ma na celu precyzyjniejsze omówienie głównych ryzyk dotyczących projektu Harmonia. + +==== Elementy systemu pozostające poza aplikacją Harmonia przeciwdziałają synchronizacji aplikacji + +[cols="1,1,1"] +|=== +| Prawdopodobieństwo | Wpływ ryzyka | Ocena ryzyka + +| 80% | 40% | Średnie +|=== + + +W produkcji dźwięku pomiędzy aplikacją, a odbiorcą dźwięków występuje wiele kroków pozostających poza kontrolą Harmonii, z czego głównymi są: + +system operacyjny:: definiujący interfejs pomiędzy programem, a sprzętowym aspektem produkcji dźwięku może wprowadzać niedeterministyczne opóźnienia. W trakcie testów zauważono, że systemy operacyjne z tej samej rodziny brzmią równiej, niż różne +połączenie głośnik-komputer:: metoda dostarczania dźwięku od komputera do głośnika może bardziej rozróżnić wykonanie - opóźnienia wynikające z działania głośnika Bluetooth są słyszalne. Dodatkowym problemem jest automatyczne usypianie głośnika, co prowadzi do dalszych opóźnień. + +Ryzyko łagodzone jest przez możliwość posiadania wspólnej konfiguracji przez osoby w orkiestrze, działanie które zostało już podjęte przez głównego odbiorcę projektu - Lambda Ensamble. + +==== Mechanizm synchronizacji nie jest odpowiedni dla synchronizacji wykonania muzycznego języka programowania + +[cols="1,1,1"] +|=== +| Prawdopodobieństwo | Wpływ ryzyka | Ocena ryzyka + +| 10% | 80% | Średnie +|=== + +Jednym z przeznaczeń Harmonii jest przygotowanie systemu sterowania wykonaniem muzycznego języka programowania Musique oraz udostępnienie API dla języków https://sonic-pi.net/[Sonic Pi], https://supercollider.github.io/[SuperCollider] oraz https://chuck.cs.princeton.edu/[ChucK]. +Wsparcie ich jest jednym z głównych długoterminowych celów projektu Harmonia. +Doświadczenie implementacji języka Musique oraz badanie działania pozostałych wymienionych środowisk łagodzi omawiane ryzyko. + +==== Orkiestra laptopowa nie wykorzysta Harmonii do nowych utworów + +[cols="1,1,1"] +|=== +| Prawdopodobieństwo | Wpływ ryzyka | Ocena ryzyka + +| 75% | 80% | Wysokie +|=== + +Harmonia jest tworzona na potrzeby istniejącego już utworu _Y_ autorstwa Wojciecha Kaszuby założyciela orkiestry laptopowej Lambda Ensamble. +Jest to utwór wyróżniający się w repertuarze orkiestry z uwagi na bardziej klasyczną strukturę i udział instrumentu smyczkowego. +Jedną z możliwych przyczyn wyjątkowości utworu jest brak systemu synchronizacji takiego jak Harmonia. + +Ryzykiem jest, że ta forma pomimo potrzeby wyrażanej przez Lambdę nie jest atrakcyjna, a Harmonia stanie się środowiskiem wykorzystywanym wyłącznie do tego utworu. +Podjętą przez Harmonię metodą łagodzenia ryzyka jest maksymalizacja użyteczności dla pozostałych utworów z repertuaru poprzez wspierania różnych poziomów synchronizacji i wygodę stosowania Harmonii w trakcie występów. + +==== Projekt Harmonia ma za mało zasobów by zrealizować zakładane cele + +[cols="1,1,1"] +|=== +| Prawdopodobieństwo | Wpływ ryzyka | Ocena ryzyka + +| 80% | 20% | Średnie +|=== + +Doświadczenie projektu Musique wskazuje na potencjalne problemy z aktualnymi zasobami dostępnymi w ramach projektu Harmonia. +Głównym elementem jest infrastruktura (CI/CD), która jest w pełni manualna lub zautomatyzowana w niewielkim stopniu. + +Głównymi obszarami, których automatyzacja wymagałaby większych zasobów ludzkich i infrastruktury sprzętowej, których dostarczenie zwiększyłoby jakość projektu: + +- automatyczne tworzenie wydań +- automatyczne testowanie synchronizacji przy pomocy maszyn wirtualnych + +Organizacja takiej infrastruktury wymagałaby dedykowanej osoby nią zarządzającą oraz stworzenia dedykowanych rozwiązań weryfikacji poprawności testów. + +==== Zastosowanie interfejsu webowego niszczy użyteczność przez wysokie zużycie energii i czasu procesora + +[cols="1,1,1"] +|=== +| Prawdopodobieństwo | Wpływ ryzyka | Ocena ryzyka + +| 40% | 40% | Średnie +|=== + +Wykorzystywany przez Harmonię interfejs webowy cechuje się dużo większym niż interfejsy natywne zużyciem zasobów. +Wynika to zarówno z narzutu wprowadzanego przez przeglądarkę i z samej konieczności wymiany informacji pomiędzy przeglądarką, a serwerem poprzez protokół HTTP i WebSockets. + +Ryzyko jest minimalizowane przez odpowiedni dobór technologii wykorzystywanych przez Harmonię, unikając rozwiązań silnie opierających się o język JavaScript i mnogość dynamicznych zmian w interfejsie. + +=== Pozostałe zidentyfikowane ryzyka + +[cols="2,1,1,1"] +|=== +| Ryzyko | Prawdopodobieństwo | Wpływ | Ocena + +| Poprawne wsparcie protokołu MIDI dla systemów Windows wymaga użycia zamknięto-źródłowego oprogramowania przez orkiestrantów +| 100% +| 1% +| Niskie + +| Nie wystarczający dobór wspieranych technologii produkcji dźwięku +| 20% +| 20% +| Niskie + +| Trudność utrzymywania projektu przez dużą liczbę zależności zewnętrznych +| 20% +| 40% +| Średnie +|=== + +== Kryteria sukcesu + +[cols="1,1,1"] +|=== +| Moduł | Kryterium sukcesu | Wskaźnik sukcesu + +| Synchronizacja wykonania orkiestry laptopowej +| Synchronizacja wspierająca wykonanie orkiestry laptopowej, umożliwiająca synchroniczny start i kontynuację utworu +| Pozytywny odbiór w trakcie tekstu z orkiestrą laptopową Lambda Ensamble + +| Interfejs odtwarzacza +| Przejrzysty i efektywny interfejs wspomagający wykonanie orkiestry jak i przygotowanie przed występem +| Interfejs jest intuicyjny i przejrzysty w ocenie orkiestry, wspomaga zarówno wykonanie jak i przygotowanie przed występem. + +| Wsparcie kluczowych form produkcji dźwięku +| Wsparcie MIDI oraz formatów audio (ogg, mp3), opcjonalne wsparcie OSC +| Wsparcie głównych form produkcji dźwięku wykorzystywanych przez orkiestrę laptopową +|===