PROJEKT SYSTEMU EWIDENCJI ZLECEŃ DLA FIRMY PROJEKTUJĄCEJ STRONY INTERNETOWE

Transkrypt

1 POLITECHNIKA GDAŃSKA WYDZIAŁ ZARZĄDZANIA I EKONOMII ZAKŁAD ZARZĄDZANIA TECHNOLOGIAMI INFORMATYCZNYMI PROJEKT SYSTEMU EWIDENCJI ZLECEŃ DLA FIRMY PROJEKTUJĄCEJ STRONY INTERNETOWE Witold Pokrzywnicki na potrzeby przedmiotu Projektowanie Systemów prowadzonego przez mgr J. Czuchnowskiego 1

2 Spis treści Rozdział 1: Analiza możliwości wykonania Podsumowanie menadżerskie Wstęp Opis problemu Model procesu biznesowego Cele Wymagania Proponowana strategia Zakres projektu Projekt obejmuje Projekt nie obejmuje Ustalenia Analiza ryzyk związanych z realizacją projektu Ryzyko technologiczne Ryzyko kompetencji Ryzyko biznesowe - efektywności Ryzyko wymagań...7 Rozdział 2: Model wymagań Aktorzy Menadżer Pracownik Klient Aplikacja Biznesowe przypadki użycia Diagram użycia systemu Opisy przypadków użycia Wymagania systemowe Systemowe diagramy przypadków użycia Opisy systemowych przypadków użycia Wymagania niefunkcjonalne...18 Rozdział 3: Model dziedziny Model statyczny Diagramy klas Dokumentacja diagramów klas...21 Rozdział 4: Model architektury oprogramowania Podziały na systemy i moduły Moduł administracyjny Moduł pracowniczy Zestawienie formularzy aplikacji Okno logowania Okno administracyjne Okno pracownicze Okno dodawania klienta Okno dodawania zlecenia

3 4.2.6 Okno przydziału pracowników do zleceń...28 Rozdział 5: Programowanie i implementacja Strategia testowania Środowisko testowe

4 Rozdział 1: Analiza możliwości wykonania 1.1 Podsumowanie menadżerskie Wstęp Projekt tworzony jest na potrzeby własne, pod moją przyszłą firmę tworzącą strony internetowe. Dotychczasowa działalność prowadzona jest na umowy o dzieło/zlecenie. Adres strony internetowej to Opis problemu Dotychczasowa działalność prowadzona jest przez jedną osobę, ale w założeniu firma ma posiadać zakontraktowanych kilku do kilkunastu pracowników. Planowane jest wprowadzenie elastycznego systemu pracy, w którym nie jest ściśle określony wymiar czasowy pracy, natomiast liczba dni, w których pracownik jest dostępny do pracy, jest zgłaszana bezpośrednio przez niego. Pracownicy zakontraktowani są na różnych stanowiskach, ale wykonywane przez nich zlecenia nie są ściśle powiązane z nazwą stanowiska. Wyznacznikiem są technologie, które pracownik zna i którymi skutecznie może się posługiwać. Zlecenia przyjmowane są przez menadżera, a pracownicy przydzielani są wg szczegółowego terminarza zlecenia, oraz ich list dostępności na miesiąc. Sam mechanizm przydziału docelowo będzie zautomatyzowany poprzez odpowiedni algorytm programu. Ofertą firmy będą zarówno projekty nowych stron, jak i przebudowy oraz aktualizacje istniejących rozwiązań. 4

5 1.1.3 Model procesu biznesowego Cele Celem wprowadzenia systemu do firmy jest ułatwienie podziału zleceń na pracowników przy nieszablonowych terminarzach gotowości do pracy Wymagania Program powinien uwzględniać różne terminy dostępności pracowników oraz terminarzy zleceń oraz ustalać przydział pracowników w taki sposób, by było to jak najbardziej efektywne Proponowana strategia Projekt zakłada stworzenie aplikacji i bazy danych oraz rozbudowywanie ich z czasem w celu spełnienia pojawiających się dodatkowych wymogów. Rozwój aplikacji uzależniony jest od rozwoju firmy. 5

6 1.2 Zakres projektu Projekt obejmuje Utworzenie aplikacji z częściową możliwością wprowadzania danych, takich jak zlecenia, nowi klienci, nowi pracownicy. Projekt obejmuje także stworzenie bazy danych oraz opcje jej przeglądania Projekt nie obejmuje Integracji algorytmu oraz mechanizmu przydziału pracowników do zleceń. Taka funkcja zostanie zaimplementowana przy ewentualnych dalszych pracach nad projektem. Baza danych zainstalowana jest jedynie lokalnie, nie ma możliwości podłączenia się aplikacją z innego komputera Ustalenia Aplikacja stworzona zostanie w formie prototypu, czyli zaimplementowana zostanie część funkcji, natomiast pozostałe zostaną jedynie zaznaczone, np. przyciski nie wykonujące żadnej funkcji, ale informujące, że taka funkcja zostanie w przyszłości wprowadzona. Dane do logowania w celu przetestowania aplikacji to: konto administracyjne: login: wp hasło: Testowe1 konto pracownicze: login: grafik hasło: Testowe1 6

7 1.3 Analiza ryzyk związanych z realizacją projektu Ryzyko technologiczne Awaria połączenia z bazą danych, błędy w wykonywaniu programu Ryzyko kompetencji Wprowadzanie błędnych danych do programu lub działanie na szkodę Ryzyko biznesowe - efektywności Program przydziela zlecenia nieefektywnie, np. nie uwzględniając rodzajów umów z pracownikami i tym samym generuje zbędne koszty. Przykład: została podpisana z pracownikiem umowa o pracę na połowę etatu, a system przydziela zlecenia pracownikom o umowach na zlecenie o tych samych kompetencjach i datach dostępności Ryzyko wymagań Wymagania postawione przed projektem okażą się niezgodne z wymaganiami firmy działającej w rzeczywistości. 7

8 Rozdział 2: Model wymagań 2.1 Aktorzy Menadżer Osoba zajmuje kierownicze stanowisko. To ona zajmuje się kontaktem z klientami, dodawaniem oraz modyfikacją klientów oraz pracowników do systemu, wprowadzaniem zleceń, oraz przyporządkowywaniem pracowników do zleceń. Ma dostęp do pełnego interfejsu aplikacji Pracownik Jest to osoba zatrudniona przez firmę oraz wykonująca prace nad zleceniami i otrzymująca za to wynagrodzenie. Ma dostęp do ograniczonego interfejsu aplikacji, gdzie może jedynie sprawdzić jakie zlecenia i kiedy są jej przydzielone, oraz wypełnić dostępność na dany miesiąc Klient Osoba kontaktująca się z menadżerem w celu złożenia zlecenia na zaprojektowanie, aktualizację lub przebudowę strony internetowej Aplikacja Wprowadzane są przez nią zlecenia, klienci, pracownicy, oraz w niej przyporządkowywani są pracownicy do zleceń. Pracownicy używają jej też do wprowadzania swojej dostępności w miesiącu. Docelowo posiadać ma także algorytm, który automatycznie będzie przydzielać pracowników, lub sugerować takie przydziały menadżerowi. 8

9 2.2 Biznesowe przypadki użycia Diagram użycia systemu Hierarchia systemu 9

10 Diagram użycia systemu 10

11 2.2.2 Opisy przypadków użycia Diagram torowy przyjęcia zlecenia 11

12 Diagram torowy przydziału zlecenia 12

13 Nazwa: Osoby: Warunki wejściowe: Warunki końcowe: Główny przepływ zdarzeń: Alternatywny przepływ zdarzeń: Przyjęcie zlecenia Menadżer, Klient, Aplikacja Są dostępni pracownicy znający odpowiednie technologie do zlecenia Zlecenie odpowiada wymaganiom postawionym przez klienta Menadżer wprowadza na podstawie ustaleń z klientem odpowiedni wpis do bazy. Ustalona zostaje data przyjęcia, oraz data 'deadline' czyli ostateczny termin oddania zlecenia. Menadżer przyporządkowuje pracowników, na podstawie ich dostępności, na każdy dzień zlecenia. Z powodu niedostępności pracowników, zlecenie zostaje odrzucone. Specjalne wymagania: Nazwa: Osoby: Warunki wejściowe: Warunki końcowe: Główny przepływ zdarzeń: Alternatywny przepływ zdarzeń: Oddanie zlecenia Menadżer, Klient, Aplikacja Prace nad zleceniem zostały ukończone Klient przyjmuje zlecenie. Po ukończeniu prac związanych ze zleceniem, menadżer przekazuje prace klientowi. Klienta zatwierdza zlecenie, menadżer wprowadza datę oddania zlecenia do bazy danych. Klient nie zgadza się na przyjęcie zlecenia, z powodu niezgodności z postawionymi wcześniej wymaganiami, lub z innego powodu. Menadżer ponownie kieruje zlecenie do poprawek jako reklamację, lub nie zgadza się z reklamacją. Specjalne wymagania: 13

14 Nazwa: Osoby: Warunki wejściowe: Warunki końcowe: Główny przepływ zdarzeń: Alternatywny przepływ zdarzeń: Specjalne wymagania: Reklamacja Menadżer, Klient, Aplikacja Klient jest niezadowolony z wykonania zlecenia. Klient odbiera ponownie zlecenie i teraz jest wszystko w porządku. Menadżer otrzymuje informację zwrotną o niezgodnościach wykonanej pracy z założeniami i wymaganiami klienta. W przypadku przyjęcia reklamacji, pracownicy zostają ponownie przydzieleni do zlecenia i wykonują nad nim prace. Zlecenie zostaje ukończone i zdane klientowi. Reklamacja zostaje odrzucona jako bezzasadna. Zlecenie zostaje poprawione, ale wraca znowu jako ponowna reklamacja. Wykonanie zlecenia wcześniej dla tego klienta. Nazwa: Osoby: Warunki wejściowe: Warunki końcowe: Główny przepływ zdarzeń: Alternatywny przepływ zdarzeń: Specjalne wymagania: Dodanie klienta/pracownika Menadżer, Klient, Pracownik, Aplikacja Pracownik nawiązuje współpracę z firmą. Nowy klient składa zlecenie. Pracownik lub klient zostają dopisani do bazy. Menadżer wprowadza wszystkie dane dot. pracownika lub klienta do bazy. Możliwa jest także ich korekta, modyfikacja i usunięcie. Pracownik lub klient nie dostarczają wszystkich wymaganych danych. Dostęp do panelu administracyjnego. 14

15 Nazwa: Osoby: Warunki wejściowe: Warunki końcowe: Główny przepływ zdarzeń: Alternatywny przepływ zdarzeń: Przypisanie pracowników do zleceń Menadżer, Pracownik, Aplikacja Wszyscy pracownicy wypełnili swoje terminarze na ten miesiąc. Wszystkie zlecenia mają przydzielonych pracowników. Na podstawie terminarzy pracowników oraz wymagań technologicznych zleceń, menadżer dokonuje przypisania pracowników do zleceń. Może także skorzystać z narzędzia automatycznego przydzielenia lub użyć go jako pomocy przy pracy. Nie wszyscy pracownicy dokonali wypełnienia swoich terminarzy, co powoduje nieprzydzielenie im pracy, a także ewentualne wydłużenie realizacji zadań lub nawet opóźnienia. Specjalne wymagania: Nazwa: Osoby: Warunki wejściowe: Warunki końcowe: Główny przepływ zdarzeń: Alternatywny przepływ zdarzeń: Specjalne wymagania: Wypełnienie terminarza Pracownik, Aplikacja Pracownik loguje się na swoje konto. Pracownik wypełnił dostępność na dany miesiąc. Po zalogowaniu się na swoim koncie, pracownik pod zakładką Moja dostępność wypełnia wolne pola. Pracownik wypełnia błędne pola, w związku z czym nie może pracować w wyznaczonym terminie, powodując opóźnienie w realizacji zadań. Pracownik zapomina wypełnić listę, w związku z czym nie otrzymuje żadnego zlecenia. Pracownik ma dostęp do swojego panelu. 15

16 2.3 Wymagania systemowe Systemowe diagramy przypadków użycia System przydziału pracowników do zleceń System wprowadzania zleceń 16

17 2.3.2 Opisy systemowych przypadków użycia Nazwa: Osoby: Warunki wejściowe: Warunki końcowe: Główny przepływ zdarzeń: Alternatywny przepływ zdarzeń: Przydział pracowników do zleceń Pracownik, Aplikacja, Menadżer Pracownik loguje się na swoje konto. Pracownik ma przydzielone zlecenie Pracownik po zalogowaniu się wypełnia dostępność na dany miesiąc. Menadżer wprowadza nowe zlecenie do programu. Aplikacja lub menadżer przypisują na podstawie harmonogramu zlecenia dostępnych pracowników. Brak dostępnych zleceń dla pracownika. Brak dostępnych pracowników do zlecenia. Specjalne wymagania: Nazwa: Osoby: Warunki wejściowe: Warunki końcowe: Główny przepływ zdarzeń: Alternatywny przepływ zdarzeń: Wprowadzenie zlecenia do bazy Aplikacja, Menadżer Menadżer loguje się na swoje konto. Zlecenie wprowadzone do systemu Menadżer loguje się do panelu administracyjnego. Wprowadza nowe zlecenie poprzez formularz. Aplikacja sprawdza poprawność wprowadzonych danych. Aplikacja wprowadza dane do bazy danych, tworzy harmonogram. Menadżer wylogowuje się. Błędne wprowadzane dane. Brak połączenia z bazą. Specjalne wymagania: 17

18 2.3.3 Wymagania niefunkcjonalne Aplikacja zainstalowana musi być na komputerze z systemem z rodziny Windows, wersja przynajmniej XP. W celu nawiązania połączenia z bazą danych, dostępne musi być połączenie internetowe. Każdy z pracowników posiada swoje własne unikalne hasło oraz login dostępu do aplikacji. Dostęp do danych klientów oraz pracowników posiada jedynie menadżer. Backup bazy danych powinien być wykonywany przynajmniej raz na miesiąc. 18

19 Rozdział 3: Model dziedziny 3.1 Model statyczny Diagramy klas Dodanie pracownika 19

20 Diagram encji 20

21 3.1.2 Dokumentacja diagramów klas Klasa Pracownik Nazwa: Opis: Przykład zastosowania: Atrybuty: Pracownik Klasa zawiera informacje o pracownikach Wprowadzenie nowego pracownika do bazy danych, porównanie wprowadzonego hasła i loginu przy logowaniu. Nazwa: Opis: Typ: haslo Hasło do logowania w panelu String (not null) login Login do dostępu do panelu String (not null) ID_prac Numer identyfikacyjny Int (not null) imie_prac Imię osoby String (not null) nazwisko_prac Nazwisko osoby String (not null) adres Ulica i numer domu String miasto Miasto String kod_pocztowy Kod pocztowy Int telefon Numer telefonu kontaktowego String mail Adres mailowy String (not null) pesel Numer PESEL String data_dol Data dołączenia do firmy DateTime (not null) data_odej Data odejścia od firmy DateTime ID_roli ID_stat Numer identyfikacyjny zajmowanego stanowiska Numer identyfikacyjny statusu pracownika Int (not null) Int (not null) 21

22 Klasa Zlecenie Nazwa: Opis: Przykład zastosowania: Atrybuty: Zlecenie Klasa zawiera informacje o zleceniu Wprowadzenie nowego zlecenia do bazy danych, przydzielenie pracowników na podstawie wprowadzonego do zlecenia harmonogramu Nazwa: Opis: Typ: ID_zlec Numer identyfikacyjny Int (identity) ID_kategoria Numer identyfikacyjny kategorii zlecenia Int (not null) ID_klient Numer identyfikacyjny klienta Int (not null) data_przyj Data przyjęcia zlecenia Datetime (not null) data_oddania Data oddania zlecenia Datetime data_deadline komentarz Data zaplanowanego oddania zlecenia Ewentualne uwagi do przyjętego zlecenia Datetime (not null) String Klasa Harmonogram Zlecenia Nazwa: Opis: Przykład zastosowania: Atrybuty: Zlecenie_terminarz Klasa zawiera informacje o harmonogramu technologii prac nad zleceniem Przydzielenie pracowników w zależności od dostępności i wymaganych technologii Nazwa: Opis: Typ: ID_zlec Numer identyfikacyjny zlecenia Int (not null) ID_technologii Numer identyfikacyjny technologii Int (not null) dzien_zlecenia Dany dzień zlecenia Int (not null) 22

23 Klasa Terminarz Pracownika Nazwa: Opis: Przykład zastosowania: Atrybuty: Prac_zlec Klasa zawiera informacje o przydzielonych pracownikowi pracach (technologiach) na poszczególne dni różnych zleceń Przydzielenie pracownikowi w zależności od dostępności prac w danej technologii do danego zlecenia Nazwa: Opis: Typ: ID_zlec Numer identyfikacyjny zlecenia Int (not null) ID_prac Numer identyfikacyjny pracownika Int (not null) dzien_zlecenia Dany dzień zlecenia Int (not null) Klasa Klient Nazwa: Opis: Przykład zastosowania: Atrybuty: Klient Klasa zawiera informacje o kliencie Wprowadzenie nowego klienta do bazy danych, dodanie zleceń dla danego klienta Nazwa: Opis: Typ: ID_klient Numer identyfikacyjny Int (identity) nazwa Nazwa firmy/klienta String (not null) miasto Miasto String adres Ulica, numer domu, mieszkania String kod_pocztowy Kod pocztowy String osoba_kontaktowa Osoba, z którą ustalane są szczegóły dot. zlecenia String mail Adres mailowy do kontaktu String (not null) telefon Numer telefoniczny Int fax Numer faxu do przesyły dokumentacji nip Numer do rozliczeń fiskalnych Int (not null) Int 23

24 Diagram sekwencji Złożenie zlecenia 24

25 Przydzielenie pracownika 25

26 Diagram maszyny stanowej a) użycia systemu Czekaj na zalogowanie Użytkownik zalogowany Czekaj na polecenie użytkownika Wykonaj polecenie Czekaj na wylogowanie 26

27 b) zlecenie 27

28 Rozdział 4: Model architektury oprogramowania 4.1 Podziały na systemy i moduły Aplikacja podzielona jest na dwa moduły: z pełnym dostępem do bazy danych dla menadżera, oraz z ograniczonym dostępem dla pracownika Moduł administracyjny Zawiera następujące zakładki: 1. Zlecenia domyślnie wyświetla domyśla listę wszystkich wprowadzonych do bazy zleceń. Opcje: - dodaj zlecenie / modyfikuj / usuń 2. Pracownicy domyślnie wyświetla domyśla listę wszystkich wprowadzonych do bazy pracowników. Opcje: - dodaj pracownika / modyfikuj / usuń 3. Klienci domyślnie wyświetla domyśla listę wszystkich wprowadzonych do bazy klientów. Opcje: - dodaj klienta / modyfikuj / usuń 4. Kategorie zleceń domyślnie wyświetla domyśla listę wszystkich wprowadzonych do bazy kategorii zleceń. Opcje: - dodaj kategorię / modyfikuj / usuń 5. Technologie pracowników domyślnie wyświetla wszystkie technologie przypisane poszczególnym pracownikom. Możliwe filtrowanie listy dla wybranego ID pracownika. 6. Terminarze pracowników domyślnie wyświetla pracowników przypisanych do prac nad zleceniami w danych technologiach. Możliwe jest filtrowanie listy po ID pracownika. Opcje: - przydziel zlecenia 7. Terminarze zleceń domyślnie wyświetla harmonogramy zleceń, czyli na jaki dzień danego zlecenia potrzebna jest jaka technologia. Możliwe filtrowanie po ID zlecenia. Opcje: - modyfikuj 8. Dostępność pracowników domyślnie wyświetla wypełnione przez pracowników dostępności w danym miesiącu. Możliwe filtrowanie po ID pracownika. Opcje: - wyczyść miesięcznie 28

29 4.1.2 Moduł pracowniczy Moduł zawiera zakładki: 1. Moje zlecenia domyślnie wyświetla wszystkie zlecenia, jakie ma przypisane zalogowany pracownik. 2. Moja dostępność umożliwia przejrzenie wypełnionej wcześniej dostępności na obecny miesiąc, a także dodanie dostępności w dniach dotychczas zaznaczonych jako niedostępne. Opcje: - edytuj 29

30 4.2 Zestawienie formularzy aplikacji Okno logowania Okno administracyjne 30

31 4.2.3 Okno pracownicze Okno dodawania klienta 31

32 4.2.5 Okno dodawania zlecenia Okno przydziału pracowników do zleceń 32

33 Rozdział 5: Programowanie i implementacja 5.1 Strategia testowania Przyjmuje si ę prowadzenie testów typu black box. Prowadzone będ ą przez wyznaczonego pracownika firmy. Produkt ma by ć przeznaczony dla wąskiej grupy użytkowników, więc osoba, która będzie bezpośrednio używał a później program jest dobrym wyborem na testera. 5.2 Środowisko testowe Do testów zostanie użyty laptop Dell z procesorem Intel Core 2 Duo 2,2Ghz, pamięcią 2GB RAM i dyskiem 250GB, wyposażony w w system operacyjny Windows 7 32-bit. Baza danych zainstalowana jest lokalnie. 33