6931258566

dodatni bądź ujemny na powodzenie przedsięwzięć podejmowanych przez początkującą firmę informatyczną.

1.2. Motywacja powstania niniejszej pracy

Motywacją autora do napisania niniejszej pracy są ponad czteroletnie doświadczenia zawodowe z zakresu współpracy z klientami pozyskiwanymi z wolnego rynku w ramach prowadzonej działalności gospodarczej w dziedzinie tworzenia internetowych, intranetowych, sieciowych i desktopowych aplikacji dedykowanych. Autor w codziennej pracy spotyka się z problemami współbieżnego zarządzania projektami w liczbie 2-5 jednocześnie. Charakter i rozmiar tych projektów pozwala z dużym prawdopodobieństwem przewidzieć to, co będzie przedmiotem prac w firmie w ciągu najbliższych 5 lat i z takim horyzontem czasowym aktualności w zamierzeniu tworzona jest wersja 1.0 aplikacji „Project manager” (zwana też, na potrzeby niniejszej pracy, „PM”). Praca została podzielona w zamierzeniu na część teoretyczną będącą uzasadnieniem zamiaru stworzenia aplikacji PM, zawierającą specyfikację i projekt aplikacji oraz na część praktyczną, działającą na serwerze, jaką jest sama aplikacja w wersji 1.0 beta. Zadaniem aplikacji PM jest centralizacja i zorganizowanie informacji dotyczących prowadzonych projektów, ułatwienie dostępu do nich i podanie ich w przejrzystej, łatwej do analizy formie oraz usystematyzowanie danych o udziałowcach ożywionych i nieożywionych mieszczących się w kontekście przedsięwzięcia, jakim jest każdy poszczególny projekt.

W rezultacie aplikacja ma pomóc zarządzać prowadzonymi projektami, jednak wspierać będzie tylko część z poniższych obszarów działań firmy.

Możemy wyróżnić:

1.    Odnalezienie klienta bądź podjęcie działań na rzecz tego, aby klient odnalazł nas (wykonawcę), badanie rynku, wnioskowanie.

2.    Rozpoznanie potrzeb klienta.

3.    Prezentację dotychczasowych osiągnięć wykonawcy klientowi.

4.    Utworzenie we współpracy z klientem w jak największym stopniu precyzyjnej

i jednoznacznej specyfikacji wymagań, a następnie sformalizowanie jej w odpowiednim stopniu. Alternatywnie pozyskanie gotowej specyfikacji technicznej lub/i funkcjonalnej.

5.    Wspólne i równoległe (z udziałem klienta) wyobrażenie sobie systemu i jego realnego działania oraz konsekwencji tego działania, burza mózgów, poprawienie i doprecyzowanie p.4, ustalenie kwestii budżetu na zmiany lub wyrażonej w % elastyczności specyfikacji, ustalenie czy specyfikacja ma być tylko mainstreamem systemu czy też zestawem sztywnych wytycznych.

6.    Wybór architektury, środowiska, podział systemu na logiczne podsystemy, moduły, funkcje.

7.    Sformułowanie treści umowy zamykającej współpracę w jednoznaczne, niejednostronne i sprawiedliwe ramy. Sterowanie ryzykiem aktywne / pasywne.

8.    Utworzenie realistycznego harmonogramu definiującego czas wykonania poszczególnych zadań / funkcji / modułów / podsystemów / systemów.

9.    Przypisanie komponentom systemu adekwatnych zasobów ludzkich: analityków, projektantów, programistów, grafików, testerów oraz wdrożeniowców.

10.    Podsumowanie projektu służące celom rozwojowym oraz formalnym (wnioskowanie, uczenie się na błędach).

Maciej Pardo www.'

li.pg.gda.pl ind 102141 ..Aplikacja do jednoczesnego zanudzania wieloma projektami informatyczny!