ocena ryzyka - internetowa ksiegarnia

Witam, jestem w trakcie tworzenia pierwszego projektu z IO, wiec proszę o wyrozumiałość.
Nie wiem jak ocenić ryzyko projektu, a konkretniej księgarni internetowej. Moim zadaniem jest wymienić i krotko opisać wszystkie elementy programu i czynniki, które mogą mieć negatywny wpływ na powodzenie projektu.

Hmm zastanawiałem się nad tym trochę, doszedłem do wniosku, że jeśli chodzi o stworzenie systemu jakim jest internetowa księgarnia, to jedynym ryzykiem byłby dla mnie czas, czyli przekroczenie wyznaczonego terminu zakończenia pracy. Jeśli chodzi o ryzyko działania takiego systemu, to ryzykiem może być usługodawca serwera ?

Nie wiem czy dobrze kombinuje, jeśli ktoś może, to niech mnie nakieruje, pozdrawiam

heh.. ryzyko przekroczenia czasu to jest wszedzie :) wyobraz sobie ze masz jakiegokolwiek zleceniodawce. jaka jest szansa ze sie rozmysli? ze zmieni wymagania? ze nagle zazyczy sobie Oracle a nie MySql? ze nagle ASP.NET a nie PHP? ze nagle ma byc polaczenie z systemem ksiegujacym, kart platniczych albo kurierskim? ze enduserom nie spodoba sie szata graficzna? ze zlecisz komus czesc pracy nad systemem i on sie nie wyrobi, zarzada wiecej $$, lub zwieje z kodem? jaka jest szansa ze sie zakochasz i uciekniesz z dziewczyna na karaiby i masz ten projekt gleboko? jaka jest szansa ze zrobisz caly projekt uzywajac MSSQL2005, bedzie pieknie dzialac na uczelni, zaliczysz semestr, pojedziesz z nim do klienta, wdrozysz, a tam .. MSSQL2000 i 80% systemu przestanie dzialac? etc etc

Głównym czynnikiem, który może mieć negatywny wpływ na nasz projekt jest czas, czyli przekroczenie wyznaczonego terminu ukończenia pracy nad projektem. Jednak ryzyko, w tym przypadku nie jest wielkie, gdyż mamy doświadczenie, w tego typu projektach i stwierdzam, iż nie jest on dla nas skomplikowany, dlatego też nie przewidujemy żadnych problemów przy tworzeniu tego projektu. Jeśli klient nie będzie zmieniał zdania co do projektu, to prace nad nim powinny zostać ukończone na czas. W przeciwnym wypadku istnieje ryzyko nie ukończenie pracy na czas, ale w takim przypadku nie bierzemy na siebie winy przekroczenia terminu. Ważnym elementem pracy jest dla nas akceptacja przez klienta postanowień ustalonych i dobrze przemyślanych na początku i trzymanie się tego, choć rozumiemy, iż czasem zmiana jest konieczna jeśli poprawi ona funkcjonowanie lub bezpieczeństwo bądź też przejrzystość czy strone wizualną projektu.

wyskrobalem coś takiego, sor za błedy pisałem bez słownika. Jeśli macie jakieś uwagi, to piszcie śmiało, pozdrawiam</ort>

To co napisales to papka dziennikarska, bez obrazy. Nic konkretnego.

Nie mozesz napisac tak po prostu, ze klient nie bedzie zmienial zdania, bo to sytuacja nierealna. Jezeli juz to napisz, co bedzie jesli specyfikacja ulegnie zmianie w trakcie projektu, jak sie zmieni czas wykonania jesli zmiany beda duze, male, na poczatku, na koncu. Jakie ryzyko niewykonania projektu przy zmianach (np. duze zmiany na koncu zazwyczaj zabijaja projekt). Oprocz tego nie wymieniles zadnych elementow projektu, ktore sa ryzykowne. Czesto to moze byc np. sprzet dostarczany przez innego dostawce, od ktorego zalezne jest dzialanie programu (czytniki, czujniki, itp). Co sie stanie jesli dostawca da ciala i nie dostarczy specyfikacji do tych czujnikow.

Innymi slowy masz opisac co sie moze zwalic przy pisaniu takiego projektu. Np. jesli glowny programista sie zwolni, pojdzie na chorobowe i tylko on wie co sie w projekcie dzieje, to lezysz i kwiczysz. Albo jakie elementy projektu moga nastreczyc trudnosci - np. ich niewykonanie (po dokladnym rozeznaniu sytuacji wyszlo, ze tak sie nie da) moze storpedowac projekt.