Praca dyplomowa magisterska

Transkrypt

1 - 1 - Praca dyplomowa magisterska Politechnika Gdańska Wydział Elektroniki Telekomunikacji i Informatyki Katedra: Katedra Inżynierii Systemów i Baz Danych Imię i nazwisko dyplomanta: Maciej Pardo Nr albumu: Forma i poziom studiów: dzienne jednolite magisterskie Kierunek studiów: Informatyka Temat pracy: Aplikacja do jednoczesnego zarządzania wieloma projektami informatycznymi Kierujący pracą: prof. dr hab. inż. Janusz Górski Zakres pracy: Celem pracy jest zaprojektowanie i implementacja prototypu aplikacji PM / Project manager ver 1.0. wspomagającej kierownika projektu zarządzającego realizacją wielu projektów informatycznych jednocześnie. Gdańsk, 2011 r.

2 - 2 - Spis treści 1. Wprowadzenie Analiza kontekstu zagadnienia zarządzania wieloma projektami IT jednocześnie Motywacja powstania niniejszej pracy Teza pracy Zakres pracy Komentarz do sposobu wersjonowania Przegląd metodyk realizacji przedsięwzięć informatycznych oraz przegląd narzędzi wspomagających zarządzanie nimi Skuteczne metodyki tworzenia projektów informatycznych na rynku polskim punkt widzenia 4-letniej firmy oraz wybór metodyki dla narzędzia PM ver Metodyki lekkie (miękkie) Metodyki ciężkie (twarde) Cykl kaskadowy Ankieta Pytanie Pytanie Pytanie Pytanie Pytanie Pytanie Wnioski z ankiety wpływające na kształt projektu aplikacji PM: Analiza stanu istniejącego - zestawienie i badanie istniejących aplikacji do zarządzania projektami Synteza i wnioski Projekt aplikacji Cel stworzenia aplikacji PM Project manager Udziałowcy problemu Sposób pozyskania wymagań Definicja Obszaru Biznesowego Obserwacja Obszaru Biznesowego objętego zakresem systemu Stosowanie technik gromadzenia informacji od udziałowców Interpretowanie pozyskanej informacji Poszukiwanie lepszych, niż dotychczasowe sposobów realizacji zadań przewidzianych dla systemu Zarejestrowanie wymagań w sposób umożliwiający w przyszłości ich jednoznaczną interpretację przez różnych odbiorców Wymagania systemowe Wymagania funkcjonalne Wymagania sprzętowe Wymagania bezpieczeństwa Wymagania użyteczności i elastyczności Wymagania wydajności Technologia realizacji Framework i język programowania analiza i wybór Architektura aplikacji Implementacja wzorca architektury MVC w Symfony [5] Moduły systemu z poziomu architektury aplikacji Moduły systemu z poziomu funkcjonalności aplikacji

3 Zastosowany system zarządzania bazami danych i koncepcja struktury danych Wady i zalety MySQL Platformy, dla których dostępny jest MySQL Zastosowanie w PM Narzędzia administracyjne dostępne do MySql Koncepcja struktury danych Miejsce przechowywania danych Diagramy UML Aktorzy Uprawnienia aktorów z podziałem na moduły Diagramy przypadków użycia Opisy diagramów przypadków użycia Klasy systemu Estymacja wielkości bazy danych Języki programowania, z wykorzystaniem których następuje implementacja aplikacji PM: Interfejs Użytkownicy Ogólny układ strony Schemat układu strony Elementy składowe strony Scenariusze testowe aplikacji, wyniki testów Walidacja poprzez scenariusze testowe Przypadki testowe dla USER_01_kierownik projektu Przypadki testowe dla USER_02 analityk systemowy Przypadki testowe dla USER_03 programista Przypadki testowe dla USER_04 tester Przypadki testowe dla USER_05 klient Test wymagań pozafunkcjonalnych Wynik testowania Przykładowy scenariusz użycia aplikacji Przeprowadzenie realizacji projektu informatycznego z użyciem aplikacji PM Project Manager Podsumowanie i kierunki rozwoju Zastosowanie praktyk TPM dla zespołu programistów Projekt modułu Scheduler Baza wiedzy komponentów i metod współdzielonych Bibliografia pracy Spis tabel, rysunków i załączników Tabele Rysunki Aplikacja PM Project manager

4 - 4 - Prawo Hofstadtera: "To zawsze zajmie więcej czasu niż się spodziewasz, nawet gdy weźmiesz pod uwagę prawo Hofstadtera." Douglas Hofstadter

5 - 5 -

6 Wprowadzenie 1.1. Analiza kontekstu zagadnienia zarządzania wieloma projektami IT jednocześnie Na przestrzeni ostatnich około pięćdziesięciu lat, kiedy to możemy obserwować sukcesywny i stopniowo intensyfikujący się rozwój informatyzacji większości dziedzin naszego życia i otoczenia, powstał szereg dziedzin badań, nauki i pracy ludzkiej, z których jeszcze kilkadziesiąt lat temu żadna nie była nawet przedmiotem wyobrażeń. W latach 30- tych dwudziestego wieku obok zawodów takich jak adwokat czy lekarz medycyny nie stawiano w jednym rzędzie takich specjalizacji jak obecnie. Analityk systemów informatycznych, analityk biznesowy, projektant UML, programista, tester czy nawet pozycjoner lub wdrożeniowiec to współcześnie samodzielne profesje, które wyrosły na gruncie nauki o informacji i stały się zawodami, w których możemy się kształcić, rozwijać i pracować tworząc wirtualną rzeczywistość, systemy ułatwiające życie innym bądź usprawniające działanie organizacji i instytucji. Jak twierdzi firma Intel [], dzięki tej tendencji rozwojowej następuje ulepszanie poziomu życia na całym świecie. Konsekwentna realizacja prawa Moore a, empirycznie ustanowionego w latach 0-tych XX-go wieku, oznacza korzyści dla ludzi, którzy używają rezultatów tego postępu, dla ludzi, których jakaś część życia poprawiła się dzięki zaawansowanej technologii. Poniższy wykres odzwierciedla tempo wzrostu optymalnej liczby tranzystorów w układzie scalonym w kolejnych latach. Daje się zauważyć trend wykładniczy: Rys.1. Prawo Moore a - wzrost liczby tranzystorów w procesorach Intela do 2004 roku

7 - 7 - Prawo Moore a [Rys.1.] jest prawem empirycznym, polegającym na obserwacji, że znajdująca swe optymalne odzwierciedlenie w ekonomii układu liczba tranzystorów składowych kształtuje się według trendu wykładniczego, podwajając się w niemal równych odcinkach czasu. Obecnie liczba ta uległa pewnej korekcie i przyjmuje się, iż liczba tranzystorów podwaja się co 24 miesiące, jednak tendencja wzrostowa regularna jest wciąż utrzymana. Analogicznie, prawo Moore a znajduje zastosowanie także w odniesieniu do innych wybranych parametrów sprzętu komputerowego, np. pojemności dysków twardych, wielkości pamięci operacyjnej, przepustowości sieci czy stosunku mocy obliczeniowej do kosztu. Nieliczne tylko parametry nie podlegają temu prawu, jak np. latencja (pamięci, dysków, sieci komputerowych) - spada ona powoli mimo rosnącej przepustowości. Informatyzacja rozumiana przez rozwój i wszechobecność zarówno hardware u (sprzętu) jak i software u (oprogramowania) jest zjawiskiem, które w sposób coraz bardziej powszechny zaczyna istnieć w świadomości osób również niezwiązanych z branżą IT. Coraz większe znaczenie automatyzacji procesów oraz aktualnej i szybko przekazanej informacji docenia dziś pojedynczy człowiek, mikroprzedsiębiorstwo, a także międzynarodowa fabryka lub korporacja zatrudniająca kilka tysięcy osób i posiadająca silnie rozproszoną strukturę w skali kraju czy całego świata. Agencja reklamowa, specjalista do spraw relacji z mediami czy prawnik pragnący dotrzeć do swoich prospektów oraz klientów. Rozwiązania informatyczne pozwalają usprawnić przepływ informacji, sprawić, że ewidencja i monitorowanie zdarzeń czy akumulacja danych staje się wygodniejsza i pewniejsza niż w przypadku, gdy działo się to na drodze tradycyjnej. Poza tym są też relatywnie tanie, nie zużywają się w aspekcie fizycznym, w wybranych przypadkach potrafią się same rozwijać a nawet uczyć i ich działanie nie jest zależne od pogody czy katastrof, jeśli tylko są serwowane w bezpieczny sposób i cyklicznie archiwizowane, duplikowane. W celu zaspokojenia nieograniczonych w swym zakresie i różnorodności potrzeb ludzkich w zakresie automatyzacji i obsługi procesów, które niedawno jeszcze musiały być realizowane przez samych ludzi, projektuje i implementuje się systemy informatyczne, których złożoność wzrasta w sposób ciągły wraz z upływem czasu. Systemy szyte przez analityków i programistów na miarę osób czy firm o bardzo różnych wymaganiach, specyfice, charakterze i budżecie za każdym razem powstają w inny sposób, dostosowany do ograniczeń i wymagań czasowych, ram prawnych, rozmiaru budżetu, warunków rynkowych, czy wreszcie gustów i potrzeb klienta (realnych i potencjalnych). Mimo to, a może właśnie dlatego próbuje się te sposoby ustrukturalizować i uzależnić stosowanie danego typu procesu wytwórczego od warunków, które można ocenić przed przystąpieniem do realizacji zadania. Na przestrzeni lat opracowano już szereg sposobów na tworzenie systemów zaliczających się do młodej dziedziny nauki, jaką jest informatyka. Zwane są one metodykami tworzenia systemów informatycznych. Aby spróbować ująć proces tworzenia oprogramowania w możliwie sztywne ramy oraz sprawować nad nim kontrolę należy zagłębić się w zagadnienia zarządzania projektami informatycznymi traktując je jako specyficzną dziedzinę zarządzania projektami pojętego ogólnie. Wśród inicjatyw komercyjnych oraz otwartych (Open Source) istnieje już szereg wartych uwagi rozwiązań w zakresie wspierania zarządzania projektem informatycznym. Cel niniejszej pracy uwzględniony w dalszej części wprowadzenia nakreślony zostanie z uwzględnieniem tych rozwiązań z naciskiem na uwypuklenie ich braków, które należałoby wypełnić projektując nowy system, którego przeznaczeniem ma być wsparcie mikroprzedsiębiorstwa wchodzącego na rynek systemów informatycznych z uwzględnieniem jak największej liczby warunków, ograniczeń, obostrzeń oraz czynników mających wpływ

8 - 8 - dodatni bądź ujemny na powodzenie przedsięwzięć podejmowanych przez początkującą firmę informatyczną 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.. 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).

9 - 9 - Aplikacja w wersji 1.0 beta nie będzie wspierać punktów: 1, 2, 3 oraz wybranych aspektów pozostałych punktów ze względu na charakter tych czynności wymagający komunikacji modułów PM z zewnętrznymi systemami. Modułowość aplikacji pozwoli dodać je w przyszłości Teza pracy Teza niniejszej pracy: Możliwe jest utworzenie przyjaznego, funkcjonalnego narzędzia wpisującego się w niszę zarządzania projektami informatycznymi przez mikroprzedsiębiorstwo wspierającego aktywne i pasywne sterowanie ryzykiem oraz optymalizację budżetów projektowych Zakres pracy W ramach teoretycznej części pracy poruszone zostały następujące tematy: - analiza najbardziej efektywnych metodyk tworzenia projektów informatycznych - wybór metodyki, którą wspierać będzie pierwsza wersja aplikacji PM - analiza istniejących rozwiązań - wybór optymalnej dla zrealizowania aplikacji technologii - projekt aplikacji z wykorzystaniem adekwatnych środków inżynierii oprogramowania - przypadki testowe gotowej aplikacji - scenariusz użycia aplikacji - kierunki rozwoju aplikacji PM Project Manager W ramach części praktycznej niniejszej pracy: - zaimplementowana została aplikacja PM Project Manager w wersji 1.0 według idei, zamysłu i artefaktów projektowych zawartych w części teoretycznej Komentarz do sposobu wersjonowania Wersja 1.0 oznacza fundamentalną funkcjonalność obejmującą wybraną metodykę Wersja 1.1 ilekroć pojawia się niniejszy zapis, nakreślone zostają ścieżki rozwoju aplikacji do kolejnej wersji, której ideą jest zbliżenie się do oprogramowania obszaru zarządzania relacją z klientem w sposób efektywny, wydajny i minimalizujący ryzyko niepowodzenia projektu.

10 Przegląd metodyk realizacji przedsięwzięć informatycznych oraz przegląd narzędzi wspomagających zarządzanie nimi 2.1. Skuteczne metodyki tworzenia projektów informatycznych na rynku polskim punkt widzenia 4-letniej firmy oraz wybór metodyki dla narzędzia PM ver. 1.0 Na potrzeby niniejszej pracy uwzględnione zostanie jedno kryterium podziału prowadzące do wyodrębnienia metodyk lekkich i ciężkich (w literaturze znajdziemy również podział o nazewnictwie: miękkie i twarde). Dla celów analiz związanych z projektem wersji 1.0 aplikacji PM formalnie nie uwzględniamy innego typu podziałów jak na przykład podział na metodyki strukturalne i obiektowe Metodyki lekkie (miękkie) charakteryzują się relatywnie niskim poziomem wymaganej formalności procesów, małym rozmiarem dokumentacji projektowej, nierzadko zaś nawet jej brakiem oraz dużą elastycznością i przy skutecznym zarządzaniu - możliwą do osiągnięcia wysoką efektywnością i dynamiką postępów prac. Znacznie węższy zakres formalizmów, mniejsza i mniej formalna dokumentacja procentować może często łatwiejszym, bardziej bezpośrednim kontaktem między członkami zespołu projektowego (udziałowcami projektu). Metodyki lekkie stanowią po części odpowiedź na znużenie i zniechęcenie zespołów projektowych do tworzenia zbyt obszernych dokumentów związanych z prowadzeniem projektu i trudnościami komunikacyjnymi wynikającymi ze zbytniego sformalizowania kanałów komunikacyjnych. Praca nad projektem prowadzona w pomieszczeniach o rozmieszczeniu stanowisk pracy pozwalających na nieprzerwaną wymianę uwag i spotkania przy tablicy głównej ze scrum masterem ma specyficzny charakter i nie każdemu informatykowi, będącemu często introwertykiem, musi odpowiadać. Jednak argumentem za jest fakt, że introwersja owa dotyczy zwykle świata zewnętrznego, nie zaś osób z branży, które poruszają kwestie znane przez obie strony. Praca w Scrum może być kontynuacją usprawnienia komunikacji i nową jakością dla zespołu oraz dla osoby mierzącej postępy, która środowisko do scrum przygotowała. Na potrzeby aplikacji PM zostanie wyodrębniony pierwszy typ metodyki, według którego możemy prowadzić projekt i nazwany zostanie XP od skrótu Extreme Programming. Wybrana metodyka lekka: Metodyka "Extreme Programming" opracowana w latach dziewięćdziesiątych XX-go wieku przez Kenta Becka i Warda Cunninghama. Możliwy kontekst wykorzystania metodyki XP w aplikacji do zarządzania projektem: Praca aplikacji w trybie XP może ograniczać się do zapewnienia projektowi wsparcia prawnego i wyznaczenia ram czasowych oraz przypisania zasobów ludzkich do pakietów tworzonego systemu. Specyfikacja odegra rolę w chwili inicjacji i zamknięcia projektu, w trakcie zaś jego trwania priorytetowe będzie zrealizowanie funkcjonalności założonej w specyfikacji. Funkcjonalność ta będzie wynikać bezpośrednio z treści specyfikacji. Wybór architektury, środowiska wytwórczego, sposobu komunikacji oraz trybu akceptowania kształtu projektu, który uznany może zostać za wystarczający do oddania do testowania w środowisku docelowym (u klienta) będzie leżał po stronie zespołu. Tryb pracy XP optymalny jest do pracy zespołów doświadczonych we wspólnej pracy, do projektów o charakterze

11 pozwalającym na częsty kontakt z klientem w celu akceptowania kolejnych przyrostów funkcjonalności bądź ustalania sposobu modyfikacji istniejących. Tryb nie zalecany do projektów o czasie trwania dłuższym niż 2 miesiące Metodyki ciężkie (twarde) Metodyki ciężkie charakteryzują się znaczną liczbą niezbędnej dokumentacji projektowej oraz sformalizowanymi procesami podejmowania decyzji, planowania, raportowania, sprawozdawczości czy odbiorów produktów itp. Metodyki ciężkie kojarzone są najczęściej z dużymi projektami i dużymi zespołami projektowymi. Nie oznacza to jednak, że nie mogą być stosowane w mniejszych projektach. Przed zastosowaniem należy jednak bezwzględnie odpowiedzieć sobie na pytanie czy ilość wymaganych przez metodykę ciężką formalnych procesów oraz dokumentów nie okaże się niewspółmierna do rozmiaru projektu i nie staniemy przed sytuacją przerostu formy nad treścią, gdzie przez treść rozumiemy wyniki implementacji. W praktyce decyzja o zastosowaniu PRINCE2 powinna być poprzedzona rozsądną i wnikliwą analizą budżetu i posiadanych do dyspozycji zasobów ludzkich w celu stwierdzenia, iż wymagane w tej złożonej metodyce procesy będzie miał kto (i w ramach założonego budżetu czyli za co) zrealizować. Do budżetu na implementację z pewnością dodać będziemy musieli niemarginalną część na samo utrzymanie projektu w kontrolowanym środowisku. W przypadku projektów dla organizacji o wysokim i szczegółowym wymaganym stopniu kontroli kosztów na każdej płaszczyźnie prac spotkać się można nawet z kontrolą jakości stosowanego papieru do drukarek czy trybu pracy drukarki, od którego zależy ilość zużywanego do drukowania tuszu. Wybrana metodyka ciężka: Metodyka PRINCE2 (Projects in Controlled Environments) została opracowana przez instytucje rządowe w Wielkiej Brytanii. Rys. 2. Oficjalne logo metodyki PRINCE2 Etapy metodyki PRINCE2, [Rys.2]., [1], [2] pozwalają na ścisłą kontrolę procesu wytwarzania i mają się jak poniżej: 1. Strategiczne zarządzanie projektem (ZS) Directing a project (DP) Proces ten realizuje funkcje, za które odpowiedzialny jest Komitet Sterujący. Kierownik Projektu informuje Komitet Sterujący w raportach okresowych o stanie projektu. Bieżące zarządzanie pozostawione jest w wyłącznej kompetencji Kierownika Projektu. Komitet Sterujący angażuje się tylko na granicach etapów zarządczych, gdzie decyduje, czy należy kontynuować prace przechodząc do następnego etapu. Fundamentalną zasadą PRINCE2 jest zarządzanie poprzez wyjątki (management by exception), co oznacza, że jedyną dodatkową sytuacją, kiedy Komitet Sterujący angażuje się w podejmowanie decyzji projektowych jest moment, gdy uzyska informacje, że projekt jest zagrożony wyjściem poza zakres tolerancji. Strategiczne Zarządzanie Projektem obejmuje następujące podprocesy: ZS1. Zezwolenie na inicjowanie projektu (DP1. Authorising Initiation) ZS2. Zezwolenie na realizację projektu (DP2. Authorising a Project)

12 ZS3. Zezwolenie na realizację etapu lub planu awaryjnego (DP3. Authorising a Stage or Exception Plan) ZS4. Podejmowanie decyzji doraźnych (DP4. Giving Ad Hoc Direction) ZS5. Zatwierdzenie zamknięcia projektu (DP5. Confirming Project Closure) 2. Planowanie (PL) Planning (PL) Planowanie jest procesem trwającym przez cały cykl życia projektu. Planowanie obejmuje następujące podprocesy: PL1. Projektowanie planu (PL1. Designing a Plan) PL2. Definiowanie i analizowanie produktów (PL2. Defining and Analysing Products) PL3. Określanie działań i zależności (PL3. Identifying Activities and Dependencies) PL4. Szacowanie (PL4. Estimating) PL5. Harmonogramowanie (PL5. Scheduling) PL. Analizowanie ryzyka (PL. Analysing Risks) PL7. Kompletowanie planu (PL7. Completing a Plan) Kroki: 1. Dokonać wyboru narzędzi i metod planistycznych 2. Przeprowadzić identyfikację produktów projektu 3. Przeprowadzić sekwencjonowanie produktów projektu 4. Zdefiniować działania, których podjęcia będzie wymagało przeprowadzenie projektu 5. Oszacować pracochłonność działań. Zbudować harmonogram 7. Dokonać oceny ryzyka 8. Zredagować plan opisowy 9. Inicjowanie projektu (Initiating a project) Aby projekt uzyskał akceptację, musi być starannie zaplanowany w sposób wystarczająco precyzyjny, aby było zrozumiałe w jaki sposób mają być zrealizowane jego cele. Wymaga to szczegółowego szacowania pracochłonności i kosztów. Wszystkie te parametry stanowią podstawę do zdefiniowania głównego dokumentu procesu, tj. Dokumentu Inicjującego Projekt, który musi zostać zaakceptowany przez Komitet Sterujący przed uruchomieniem etapu realizacji. 3. Uruchamianie Projektu/Przygotowanie Założeń Projektu (PP) Starting up a project (SU) Inicjowanie projektu obejmuje następujące podprocesy: IP1. Planowanie jakości (IP1. Planning Quality) IP2. Planowanie projektu (IP2. Planning a Project) IP3. Doprecyzowanie Uzasadnienia Biznesowego i Ryzyka (IP3. Refining the Business Case and Risks) IP4. Ustanowienie elementów sterowania (IP4. Setting Up Project Controls) IP5. Ustanowienie dokumentacji projektowej (IP5. Setting Up Project Files) IP. Zestawienie Dokumentu Inicjującego Projekt (IP. Assembling a Project Initiation Document) Projekty realizowane według metodyki PRINCE2 są podzielone na etapy zarządcze. Dokładna ilość etapów nie jest zdefiniowana, zależy ona od wielkości projektów, poziomu ryzyka i ilości planowanych punktów decyzyjnych, w których następowałaby decyzja, czy projekt jest nadal uzasadniony biznesowo i czy należy kontynuować prace. W tym procesie realizowane jest bieżące zarządzanie projektem Kierownika Projektu.

13 Sterowanie Etapem (SE) Controlling a stage (CS) Sterowanie etapem obejmuje następujące podprocesy: SE1. Zgoda na wykonanie grupy zadań (CS1. Authorising Work Package) SE2. Ocena postępów (CS2. Assessing Progress) SE3. Rejestrowanie zagadnień projektowych (CS3. Capturing Project Issues) SE4. Analizowanie zagadnień projektowych (CS4. Examining Project Issues) SE5. Przeglądanie stanu etapu (CS5. Reviewing Stage Status) SE. Raportowanie o ważnych zdarzeniach (CS. Reporting Highlights) SE7. Podejmowanie działań korekcyjnych (CS7. Taking Corrective Action) SE8. Eskalowanie zagadnień projektowych (CS8. Escalating Project Issues) SE9. Odbieranie wykonanej grupy zadań (CS9. Receiving Completed Work Package) Kroki etapu: 1. Zebrać dane o pracach wykonanych w bieżącym etapie 2. Opracować plan kolejnego etapu lub plan wyjątkowy oraz zaktualizować plan projektu 3. Sprawdzić, czy zaszły zmiany w uzasadnieniu biznesowym i ryzyku 4. Przygotować raport dla Komitetu Sterującego 5. Zarządzanie wytwarzaniem produktów (Managing product delivery) PRINCE2 to metodyka oparta na produktach etapów. Produktem może być rzecz materialna np. podręcznik. Może nim być też rzecz niematerialna np. poziom usług serwisowych. De facto wszystko, co zostało wytworzone przez projekt zgodny z PRINCE2 - włączywszy dokumenty - jest produktem. Produkt może być wytworzony przez kogokolwiek, również przez zewnętrznego dostawcę. W tym procesie wytwarza się produkty specjalistyczne projektu, dla których został on uruchomiony i w tym procesie pożytkowana jest zdecydowana większość zasobów. 5. Zarządzanie Wytwarzaniem Produktów (WP) Managing product delivery (MP) Zarządzanie Wytwarzaniem Produktów obejmuje następujące podprocesy: WP1. Przyjęcie grupy zadań do realizacji (MP1. Accepting a Work Package) WP2. Wytwarzanie grupy zadań (MP2. Executing a Work Package) WP3. Dostarczanie grupy zadań (MP3. Delivering a Work Package) Kroki: 1. Ustalić zakres prac z kierownikiem projektu 2. Zaplanować prace zespołu 3. Nadzorować prace zespołu 4. Składać raporty z jakości produktów i postępów prac 5. Uzyskać zatwierdzenie wykonanych produktów. Zarządzanie zakresem etapu (Managing stage boundaries) 7. Zgodnie z PRINCE2 każdy etap musi być ukończony i zaakceptowany zanim Komitet Sterujący autoryzuje przejście do następnego etapu. W tym procesie weryfikowane jest, czy etap dostarczył wszystkie wymagane produkty i czy pierwotne parametry biznesowe nie uległy zmianie. Planowany jest też w tym kontekście uszczegółowiony plan następnego etapu.. Zarządzanie Zakresem Etapu (ZE) Managing stage boundaries (SB) Zarządzanie Zakresem Etapu obejmuje następujące podprocesy: ZE1. Planowanie etapu (SB1. Planning a Stage) ZE2. Uaktualnienia planu projektu (SB2. Updating a Project Plan)

14 ZE3. Uaktualnienie uzasadnienia biznesowego projektu (SB3. Updating a Project Business Case) ZE4. Uaktualnienie rejestru ryzyka (SB4. Updating the Risk Log) ZE5. Raportowanie końca etapu (SB5. Reporting Stage End) ZE. Opracowanie planu naprawczego (SB. Producing an Exception Plan) ZE7. Zamykanie projektu (Closing a project) Zgodnie z metodyką PRINCE2 projekty muszą być zamykane w sposób uporządkowany i kontrolowany. Doświadczenia pozyskane w trakcie prowadzenia projektu są rejestrowane, tworzony jest dokument przekazania i planowany jest przegląd powdrożeniowy. Po zakończeniu projektu w zaplanowanym momencie pozwalającym na należytą ocenę skutków biznesowych projektu przeprowadzany jest przegląd poprojektowy będący podstawą do akceptacji produktów procesu. 7. Zamykanie Projektu (ZP) Closing a project (CP) Zamykanie projektu ma następujące podprocesy: ZP1. Przygotowanie projektu do zamknięcia (CP1. Decommissioning a Project) ZP2. Określanie działań następczych (CP2. Identifying Follow-on Actions) ZP3. Przegląd oceniający projekt (CP3. Project Evaluation Review) Kontekst możliwego wykorzystania metodyki PRINCE w aplikacji PM: Metodyka znaleźć może zastosowanie w projektach o czasie trwania przekraczającym 4 miesiące. Dla mniejszych (krótszych) projektów jej stopień skomplikowania może okazać się przytłaczający i wpłynąć negatywnie na powodzenie projektu poprzez mnożenie kosztów na obsługę procesów, które nie przekują się na realny postęp i produktywną kontrolę Cykl kaskadowy [3] Rys. 3. Model kaskadowy Pod kątem złożoności czasowej i strukturalnej za formę pośrednią pomiędzy dwiema powyższymi metodykami (1.5.1 i ) można uznać powszechnie znany cykl kaskadowy [Rys.3.]. Nierzadko spotkać można opinie, iż cykl ten powinien być stosowany zwłaszcza do projektów o ograniczonej odpowiedzialności bądź kontrolowanym ryzyku. Zaleca się go często do projektów o małym zakresie lub studenckich. Przypadek przejścia z metodyki Waterfall do Agile opisany został w artykule pt. The Accidental Agilists: One Team s Journey from Waterfall to Agile [4]. Osoba z zespołu wytwórczego TSO pracująca nad

15 kilkumiesięcznym projektem dla Uniwersytetu w Ohio jako jedną z przyczyn dynamicznego zaistnienia potrzeby migracji na metodykę Agile w trakcie trwania projektu podaje rozrośnięcie się etapu analizy ponad zakładany w harmonogramie czas, co już na początku procesu wytwarzania poddało pod wątpliwość szansę na zakończenie projektu sukcesem w krótkim terminie, który narzucony został przez harmonogram. Narastającą frustrację w zespole TSO powodowało wiele czynników będących przyczynami opóźnień. Niektórzy członkowie zespołu pozostawieni sami sobie oraz metodyce nie czuli się upoważnieni do podejmowania ważnych decyzji. Inni, którzy nie mieli doświadczenia w pracy przy procesie wytwarzania oprogramowania założyli z góry, że zespół deweloperów po prostu poradzi sobie z wymaganiami i zaimplementuje je w całości za pierwszym podejściem. Jednak zmaterializowało się jedno z podstawowych ryzyk w takich przypadkach i w jednym z etapów kluczowy programista opuścił uniwersytet, który był miejscem prowadzenia prac. Zespołowi zabrakło elastyczności i nawiązania bliskiej współpracy z klientami systemu, jakimi byli wykładowcy uniwersytetu i to oni mogli podejmować decyzje i wspierać zespół w trwających pracach. Sama metodyka Waterfall nie zawiera praktyk wspierających dynamikę komunikacji między udziałowcami. Innymi często podawanymi w literaturze uwagami krytycznymi metodyki kaskadowej są: - sztywna struktura schodków, która może być niedopasowana do wysokiej złożoności modelowanej rzeczywistości - brak pełnej i realnej możliwości przewidzenia trudności implementacyjnych w danej technologii przez projektantów na etapie projektowania (założenie: zaprogramują! ) - niemożność lub zbyt duży koszt powrotu z fazy następnej do poprzedniej w przypadku zmiany wymagań klienta po zakończeniu jednego z etapów - wzrastający koszt zmian i modyfikacji wraz z wkraczaniem w kolejną fazę projektu cyklu kaskadowego Czy zatem istnieje uniwersalna metoda, która pozwoliłaby zwiększyć zaufanie do metodyki waterfall? Praktyka pokazuje, że tak. Okazuje się bowiem, że cykl kaskadowy, z odpowiednio dobranym wzbogaceniem elementami metodyki Scrum, na gruncie komunikacji z klientem może być szkieletem organizacyjnym dla wykonania nawet dużych, odpowiedzialnych przedsięwzięć. Jednym z powodów jest fakt, że przy odpowiednio intensywnej i skutecznej kontroli produktów każdego etapu oraz przy założeniu adekwatnego, kilkuprocentowego budżetu na zmiany, można wynegocjować i przeprowadzić duży projekt w metodyce kaskadowej, choćby ze względu na niezwykle wysoką zdolność tej metodyki do zapewnienia widzialności projektu u klienta. Jest ona w wysokim stopniu intuicyjna i pozwala osobom na wielu szczeblach organizacji przybliżyć założenia organizacyjne niezrozumiałych prac informatyków. Spowodowane jest to między innymi prostą strukturą metodyki waterfall, którą z powodzeniem można zaprezentować w sposób zrozumiały i, co ważne, przekonujący o potencjalnie wysokim stopniu możliwej kontroli przez klienta. Scrum zakłada częsty bezpośredni kontakt między udziałowcami projektu. Praktykę tę wystarczy wdrożyć na wszystkich szczeblach komunikacji zapewniając ją choćby narzędziem Trac, a nawet prostym web-forum, dzięki czemu każdy kluczowy udziałowiec systemu pozostaje in-touch z aktualnymi i przewidywanymi problemami. Prowadząc projekt oficjalnie w metodyce waterfall nie należy zapominać o podstawowych założeniach manifestu Agile, mieć je na uwadze i wprowadzać w klimat prac zespołu jako osoba wspierająca odpowiednią metodykę prowadzenia projektu: 1. Individuals and interactions over processes and tools Ludzie i współpraca ponad procesami i narzędziami.

16 Working software over comprehensive documentation Działający program jest ważniejszy niż wyczerpująca dokumentacja. 3. Customer collaboration over contract negotiation Współpraca z klientem jest ważniejsza od negocjacji warunków kontraktu. 4. Responding to change over following a plan Reakcja na zmiany nie mniej ważna od podążania za wytyczonym planem. Projekt to jednak nie tylko metodyka. Bez świadomości osoby zarządzającej dotyczącej złożoności charakterów ludzkich, cech, zachowań, nawyków, umiejętności, skłonności (lub jej braku) do zachowań społecznych, umiejętności tworzenia grup, społeczności, doświadczeń czy wreszcie ludzkich braków i wad żadna metodyka nie zdałaby egzaminu. Projekt IT niesie za sobą konieczność połączenia ze sobą w jeden zespół ludzi o skrajnie różnych interesach (klient, wykonawca), charakterach (niemalże każdy przykład relacji), sposobach komunikowania się (programista, manager), płciach czy stażu zawodowym (wzajemne uczenie się). Te i wiele innych relacji, które na gruncie psychologii dają się opisać i zamknąć w pewne konkretne ramy wraz z wyborem metodyki projektu, czyli drogi, po której zespół ludzi ma podążać mogą być dopiero kluczem do sukcesu projektu. W związku z powyższym pod uwagę przy doborze metodyki należy wziąć fakt, na ile ułatwia ona (bądź komplikuje) komunikację w zespole i czy zespół sobie z tym poradzi i czy każdy udziałowiec wyjdzie z projektu z poczuciem wygranej w założonych ramach budżetu czasowego i finansowego. Dobór trzech powyższych metodyk jest optymalny ze względu na wynik przeprowadzonych statystyk wewnętrznych, według których w okresie 4 lat i wykonanych ponad 30 różniących się diametralnie obszarem zleceń z zakresu informatyki, dało się wyodrębnić właśnie te 3 rodzaje procesów wytwórczych. Jeśli nawet dany proces nie wpisywał się jednoznacznie w jedną z 3 metodyk, to w każdym przypadku do jednej z nich był bardziej zbliżony niż do każdej ze zbioru wszystkich pozostałych metodyk w wyłączeniem przedmiotowych trzech (np. cykl spiralny). Kontekst możliwego wykorzystania metodyki kaskadowej w aplikacji PM: Dla wersji pierwszej aplikacji PM (ver 1.0) zaimplementowana zostanie obsługa metodyki kaskadowej z elementami Scrum, kolejne będą mogły być opracowane w ramach rozwinięcia pracy Ankieta W procesie projektowania funkcjonalności aplikacji pod uwagę została wzięta ankieta przeprowadzona wśród zaprzyjaźnionych właścicieli firm mających doświadczenie w przeprowadzaniu procesu wytwarzania oprogramowania. Trafiła ona do 10 osób z obszaru Gdańska, Gdyni oraz Sopotu. Ankieta miała na celu pozyskanie oceny proponowanych do tej pory funkcjonalności oraz zasięgnięcie opinii na temat tego, jakie jeszcze funkcjonalności powinny być zawarte w aplikacji PM. Celem przeprowadzenia ankiety jest również zbadanie użyteczności aplikacji PM poprzez sprawdzenie opinii osób znajdujących się w grupie potencjalnych użytkowników programu. Wśród badanych znaleźli się dyplomanci i doktoranci kierunku informatyka Politechniki Gdańskiej oraz osoby związane z Wydziałem Informatyki Uniwersytetu Gdańskiego.

17 Pytanie 1 Jaką rolę odgrywasz w swojej firmie/organizacji? Rys. 4. Wykres ról ankietowanych w firmach, w których pracują [Rys.4.] Obrazuje rozkład ról (stanowisk) piastowanych przez badane osoby w swoich organizacjach. Programista osoba odpowiedzialna za implementację rozwiązań pokrywających potrzeby biznesowe klientów. Właściciel osoba decyzyjna w organizacji czy firmie. Wśród odpowiedzi na pytanie jaką inną funkcję pełni ankietowany w organizacji najczęściej pojawiały się odpowiedzi: - analityk systemowy [75% odpowiedzi inne] - tester [25% odpowiedzi inne] Pytanie 2 Czego brakuje Ci w aplikacji do zarządzania projektami, z której korzystasz? Rys. 5. Wykres pożądanych cech aplikacji do zarządzania projektami

18 [Rys.5.] Obrazuje cechy oprogramowania do zarządzania projektami, które ankietowani wypunktowali jako przydatne im w codziennej pracy. Większa prostota obsługi ergonomia interfejsu, intuicyjność pracy z aplikacją, brak nadmiarowych funkcji Większa złożoność zdolność do obsługi bardziej skomplikowanych procesów np. nie tylko komunikacja wewnątrz zespołu, lecz również wsparcie dla komunikacji z udziałowcami zewnętrznymi, nieożywionymi (np. przepisy prawa). Wśród odpowiedzi na pytanie jakie inne, niż wymienione w ankiecie, funkcje są potrzebne wymieniano: - kompleksowość obsługi newralgicznych procesów [25%] - alertowanie o pojawiających się niebezpieczeństwach [25%] - ułatwienie dostępu do rozproszonych informacji przez ich centralizację [25%] - zapobieganie konieczności przeprowadzania papierowego obiegu dokumentów (ekologia, aspekty zagubienia i utraty kluczowych informacji) [12,5%] - funkcje wspomagające nałożenie ram w płaszczyźnie współdzielonej z klientem, na którą ma on bezpośredni lub pośredni wpływ [12,5%] Pytanie 3 Ile osób pracuje średnio w Twojej firmie lub współpracuje w zakresie, w którym kontrolować/zarządzać nimi? Rys.. Wykres ilości pracowników badanych firm [Rys..] Obrazuje wielkość badanych firm mierzoną wielkością zatrudnienia.

19 Pytanie 4 Co jest najważniejsze w procesie wytwarzania oprogramowania dedykowanego tworzonego według specyfikacji klienta? Tab.1. Wyniki pytań ważonych ankiety Ramy wyznaczone przez umowę na wykonanie Dokładność specyfikacji / niska zmienność wymagań Jakość produktu końcowego Kontrola procesu wytwarzania i programistów Wynik testowania przez wykonawcę Wynik testowania przez klienta SUMA 1 (10,00%) 1 (10,00%) 0 (0,00%) 0 (0,00%) 0 (0,00%) 0 (0,00%) 1 (10,00%) 1 (10,00%) 0 (0,00%) 1 (10,00%) 1 (10,00%) 0 (0,00%) 2 (20,00%) 2 (20,00%) 0 (0,00%) 1 (10,00%) 1 (10,00%) 0 (0,00%) 2 (20,00%) 2 (20,00%) 1 (10,00%) 3 (30,00%) 3 (30,00%) 0 (0,00%) 3 (30,00%) 4 (40,00%) 1 (10,0%) 3 (30,00%) 1 (10,00%) 2 (20,00%) 1 (10,00%) 33 Nie mam zdania Liczba odpowiedzi 0 (0,0%) 10 0 (0,0%) 37 0 (0,0%) 10 8 (80,00%) 2 (20,00%) 4 (40,00%) 8 (80,00%) 57 0 (0,0%) (0,0%) 10 0 (0,0%) (0,0%) 10 Odpowiedzi na pytanie nr4 pozwalają ocenić, który z wymienionych czynników zdaniem ankietowanych ma największy wpływ na powodzenie projektu. Wnioskując z tabeli [Tab.1.] najważniejszymi czynnikami są jakość produktu końcowego i wynik testowania u klienta. Dwa powyższe parametry są ze sobą ściśle związane. Inżynieria oprogramowania nie definiuje jednoznacznie pojęcia jakości oprogramowania, ani momentu, w którym jest ona osiągnięta. Jakość odbierana subiektywnie przez klienta może być dla producenta oprogramowania dedykowanego sygnałem do zakończenia prac nad danym przyrostem i uznania osiągniętej jakości za odpowiednią Pytanie 5 Z jakim systemem baz danych preferują pracować Twoi pracownicy? Rozkład odpowiedzi wśród 10 ankietowanych: Tab.2. Zestawienie najczęściej wybieranych silników baz danych MySql PostgreSQL Firebird Oracle DB2 MSSQL Informix SQLite

20 [Tab.2.] Wnioskując z odpowiedzi na pytanie 5. MySql uznany może być za najczęściej wybierany wśród ankietowanych silnik baz danych. Często podawanymi powodami są: - intuicyjność obsługi - stabilność i de facto brak błędów, co nie zawsze może być powiedziane, jeśli chodzi o ocenę baz firmy Microsoft - otwarta licencja Pytanie Który framework do PHP uważasz za najefektywniejszy? Rozkład odpowiedzi wśród 10 ankietowanych: Tab.3. Zestawienie najczęściej wybieranych frameworków PHP Ash.MVC Cake Codeigniter DIY ez_components Fusebox on PHP TRAX PHPDevShell PHPOpenBiz Prado QPHP Seagull Symfony WACT WASP Yii Zend [Tab.3.] Wnioskując z odpowiedzi na pytanie. framework Symfony uznany może być za najczęściej wybierany wśród ankietowanych Wnioski z ankiety wpływające na kształt projektu aplikacji PM: - ankieta została przeprowadzona wśród reprezentantów potencjalnej grupy docelowej aplikacji PM posiadających wykształcenie wyższe techniczne, mających styczność bezpośrednią z klientami na aplikacje informatyczne lub z samym procesem wytwórczym - ankieta dostarczyła zewnętrznego spojrzenia na koncepcję autora niniejszej pracy - zapotrzebowanie na aplikację oprogramowującą płaszczyznę bezpośredniej współpracy z klientem o otwartym kodzie na licencji GPL jest wysokie - najpopularniejszą bazą danych wśród małych i średnich aplikacji internetowych jest MySql - najbardziej cenionym wśród ankietowanych frameworkiem jest Symfony

21 Analiza stanu istniejącego - zestawienie i badanie istniejących aplikacji do zarządzania projektami Do zestawienia wybrane zostały najbardziej popularne programy w wersjach darmowych. Wersje płatne z uwagi na niekonkurencyjność względem tworzonej w ramach niniejszej pracy aplikacji nie były brane pod uwagę. Poniżej znajduje się lista wybranych do porównania aplikacji o funkcjonalności pokrywającej różne obszary zarządzania projektami informatycznymi: 1. Microsoft Project Professional [8] 2. Blue Ant [9] 3. Microsoft Project Standard [10] 4. Milestones Proffesional 200 [11] 5. Baser [12]. Yapp the project calculator [13] 7. PhProjekt [14] 8. PhpCollab [15] 9. Project Open [1] 10. ProjectPier [17] 11. Open Workbench [18] 12. Windows Planner [19] 13. OpenProj [20] 14. GanttProject [21] 15. Product Based Planner [22] 1. dotproject [23] 17. PM Support na 4pm.pl [24] 18. PM Support instalowany u klienta [25] 19. ATTASK [2] 20. Replicon Web Time Sheet [27] 21. Project Insight [28] 22. Copper 2007 [29] 23. egroupware [30] 24. Primavera [31]

22 Tab.4. Zestawienie aplikacji do zarządzania projektami dostępnych na licencjach bezpłatnych A B C D E F G H I J K L M - O P R S Podstawowe możliwości funkcjonalne aplikacji T T T T T T T T T T T T T T T T T T T T T T T T T T T - - T T T T T T - T T - T T T - T T T T - - T T T - - T - T T T - T - - T - T T T T T T T T T T T T T T T T T T T T T T T T - T T T T T - T - T - T T T - - T T T - T T T - T T T T - T - - T T T - - T T T T T T - - T T T T - T T T T T T T T - T - T T T - T T - T - T T T T T - T - T T - T - T T T T T T T T T T T T T T T T - T - T T T T T T T T T T T T T - T T - T - T T T T T T T T T T T T T - T T T - T T T - T T T T - T T T - T T T T T T T T - T - T T T - T T T T - T - - T - T T T - - T - T T T T - - T T T T T T - - T T T T T T T - - T T T T T T T T - T - T T - - T T T T T T - T P P P B P B P B B B B B B P B B B P P P P B P P Oznaczenie wierszy: A Zarządzanie portfolio projektów B Lista zadań C Ustalanie terminów zadań na podstawie terminów zadań zależnych D Ustalanie kosztów zadań E Definiowanie kalendarza projektu F Narzędzia służące do analizy ryzyka G Śledzenie stanu projektu w % H Komentowanie stanu I Śledzenie kosztów projektu J Powiadamianie o ważnych zdarzeniach za pomocą K Przypisywanie osób do zadań L Przypisywanie innych zasobów M Balansowanie zasobów N Jednoczesna praca wielostanowiskowa

23 O P R S T Możliwość zdalnej pracy przez WWW Możliwość dołączania dokumentów Wykres Gantta Forum dyskusyjne P płatna B - bezpłatna Synteza wnioski z [Tab.4.] 1. Niemal żadne z bezpłatnych narzędzi nie zawiera modułu do analizy ryzyka powodzenia projektu. 2. Około połowa rozwiązań nie zawiera funkcjonalności dostarczających informacje o postępach projektu w %. 3. Prawie żadne bezpłatne rozwiązanie nie realizuje funkcjonalności śledzenia kosztów projektu. 4. Balansowanie zasobów (eliminacja wąskich gardeł i przestojów) jest funkcją, która nie występuje w żadnej darmowej aplikacji 5. Możliwość dołączania dokumentów występuje w mniej niż połowie badanych aplikacji, co za tym idzie możliwość przekrojowego badania stanu projektu jest silnie ograniczona. Nie istnieją rozwiązania klasyfikujące podprocesy w procesach wytwarzania oprogramowania na pasożytnicze i producenckie oraz agregujące statystyki wydajności czasu poświęconego przez udziałowców po stronie wykonawcy na pracę nad poszczególnymi etapami (ze szczególnym uwzględnieniem etapu maintenance u Klienta).

24 Projekt aplikacji 3.1. Cel stworzenia aplikacji PM Project manager Poprzez zaprototypowanie środowiska do jednoczesnego zarządzania wieloma projektami informatycznymi autor zamierza usprawnić proces współpracy z klientami organizacji świadczącej usługi w zakresie tworzenia dedykowanych aplikacji o specyfikacji zdefiniowanej wspólnie z klientem wspierając obszary konfliktowe. System planowany jest jako kontroler stanu projektów nadzorujący przebieg ich wykonania oraz wspomagający osobę zarządzającą w zauważaniu powstających problemów i zagrożeń. System umiejscowiony jest przekrojowo przez większość poziomów abstrakcji z biznesowego punktu widzenia - od uświadomienia potrzeby, zrodzenia idei i założeń systemu, przez specyfikację wymagań i umowę o współpracę, aż po przypisanie zasobów ludzkich do zadań i prowadzenia repozytorium wyników tych prac. Jednoczesność zarządzania kilkoma różnymi projektami daje użytkownikom szereg korzyści: i. wspólne repozytorium wiedzy pozwalające wykorzystywać szablony i wzorce czynności z innych projektów w kolejnych (reusability) ii. kontrola i wgląd w historię uczenia się firmy iii. bezpośredni materiał do wnioskowania o błędach i polach do usprawnień w zakresie całej organizacji (analiza materiałów pochodzących ze wszystkich projektów realizowanych przez firmę) iiii. nadawanie określonego stopnia zaufania konkretnym metodom i procesom w empirycznie sprawdzonych kontekstach projektowych. Wspieranie zarządzania ryzykiem i osiągnięcia jak najwyższej powtarzalności procesów wytwarzania oprogramowania zakończonych sukcesem w przyszłości. iiiii. przeprowadzenie klasyfikacji procesów składających się na proces wytwarzania dzieląc je na procesy po stronie pasożytniczej i po stronie producenckiej oraz zastosowanie praktyk Total Preventive Maintenance [37] do dziedziny utrzymania projektów informatycznych w celu stworzenia precyzyjnej metody zarządzania ryzykiem i kosztami wytwórczymi i pielęgnacyjnymi. Pozostałe cele związane z korzyściami firmy pracującej z aplikacją PM Project Manager: - obniżenie czasu i kosztów komunikacji wewnątrz zespołu - wejście w posiadanie dodatkowych argumentów marketingowych

25 efektywniejsze szacowanie i kontrola zasobów i postępów prac - łatwiejsze dążenie do zwiększenia konkurencyjności produktów i usług - zwiększenie płynności finansowej 3.2. Udziałowcy problemu Udziałowcy systemu: - właściciel / dyrektor operacyjny firmy korzystającej z aplikacji, - kierownik projektu, - analityk systemowy, - programista, - tester funkcjonalny, - wdrożeniowiec, - audytor oraz wywierające wpływ na te osoby bądź pozostające pod ich bezpośrednim wpływem w kontekście realizowanego projektu. Po stronie klienta wgląd do systemu może mieć osoba reprezentująca organizację klienta (dyrektor operacyjny, właściciel, account manager, kierownik projektu). Nie przewiduje się, aby z wersji 1.0 systemu korzystało jednocześnie więcej niż 100 użytkowników Sposób pozyskania wymagań Definicja Obszaru Biznesowego Pozyskanie wymagań zainicjowane zostało definicją Obszaru Biznesowego, do którego zaklasyfikowana zostanie budowana aplikacja oraz w ramach którego będzie wykorzystywana. Definicja ta bezpośrednio implikuje obszar wiedzy dziedzinowej, którą należy pozyskać, aby rzetelnie zaprojektować działanie programu. Bez ustanowienia granicy dziedziny problemowej oraz uświadomienia sobie zakresu wiedzy z tejże dziedziny nie byłaby możliwa produkcja aplikacji wpisującej się w potrzeby specyficzne dla obszaru lub obszarów, których dotyczy. Granica ta jest określona poprzez przepływy występujące pomiędzy rozpatrywanym problemem i jego otoczeniem, które mogą dotyczyć dokumentów, komunikacji (np. rozmów telefonicznych), przedmiotów itp. Otoczenie to może być

26 - 2 - identyfikowane np. jako odbiorca usług i produktów dostarczanych przez obszar biznesowy objęty zainteresowaniem. [38] Rys.7. Ustalenie zakresu problemu Obserwacja Obszaru Biznesowego objętego zakresem systemu Obserwacja Obszaru Biznesowego miała miejsce na drodze praktycznej realizacji projektów informatycznych w realnym środowisku biznesowym, w związku z czym bezpośrednim źródłem wymagań jest autor niniejszej pracy. Zostały wyodrębnione kluczowe dla skutecznego przeprowadzenia projektu procesy biznesowe pokrywające się z etapami metodyki kaskadowej wytwarzania oprogramowania poszerzone o elementy metodyki Scrum. Udziałowcami stanowiącymi źródło wymagań na system PM Project manager byli pracownicy firmy wykonawczej realizującej dedykowane aplikacje na podstawie ustalonej z klientem lub klientem i użytkownikami systemu specyfikacji wymagań Stosowanie technik gromadzenia informacji od udziałowców Interpretowanie pozyskanej informacji w taki sposób, by oddzielić rzeczy istotne od szczegółów Selekcja informacji wywierających wpływ na treść i stopień szczegółowości pozyskiwanych wymagań miała miejsce na drodze celowego pominięcia zagadnień dotyczących aktualnie stosowanych technologii i formułowanie wymagań w sposób ogólny, odzwierciedlający istotę

27 pracy przewidzianej dla systemu z punktu widzenia funkcjonalności, nie zaś sposobu jej zrealizowania. Wymagania zostały wyspecyfikowane w sposób umożliwiający swobodny wybór technologii wytwarzania i architektury aplikacji na etapie projektowania systemu Poszukiwanie lepszych, niż dotychczasowe sposobów realizacji zadań przewidzianych dla systemu W drodze obserwacji szeregu parametrów (m.in. skuteczność, mierzalność wyników, zdolność do wsparcia zapewnienia terminowości prac) stosowanej w procesie wytwarzania oprogramowania metodyki wymagania konstruowane były z dążeniem do uzyskania aplikacji w sposób innowacyjny wykorzystującej znane metody w celu osiągnięcia jak największej wartości dodanej wynikającej z jednoczesności prowadzenia projektów oraz z nowatorskiego podejścia do znanych zagadnień Zarejestrowanie wymagań w sposób umożliwiający w przyszłości ich jednoznaczną interpretację przez różnych odbiorców Wymagania zostały wyrażone precyzyjnie i wyznaczone zostały w sposób lokujący każde z nich na podobnym poziomie abstrakcji. Sposób zarejestrowania wymagań uwzględniał możliwość łatwego przełożenia ich na przypadki użycia na etapie projektu systemu, co pozwoliło zwiększyć weryfikowalność wymagań za pomocą testowania konkretnych przypadków użycia na etapie weryfikacji funkcjonalności. Przeprowadzenie pozyskania, identyfikacji i rejestracji wymagań odbyło się z uwzględnieniem pracy wymaganej do wykonania w Obszarze Biznesowym, ale również z uwzględnieniem przyszłych potrzeb. Na tej podstawie wyznaczono również kierunki rozwoju aplikacji.

28 Wymagania systemowe Wymagania funkcjonalne RQ_001 Powiązania: Możliwość wyboru projektu Każdy użytkownik systemu powinien mieć możliwość wyboru projektu, nad którym chce pracować po zalogowaniu się. System powinien obsługiwać listę użytkowników o loginach i hasłach ustalonych przez administratora. System nie przewiduje możliwości samodzielnej rejestracji użytkowników. USER_01, USER_02, USER_003, USER_004, USER_005, UCS_000, USER_01_UCS_001, USER_01_UCS_002, USER_01_UCS_003, USER_01_UCS_004, USER_01_UCS_005, USER_01_UCS_00, USER_02, USER_03, USER_04 RQ_002 Powiązania: Możliwość korzystania z modułu stanowiącego repozytorium dokumentów prawnych Kierownik projektu powinien mieć dostęp do dokumentów w formacie *.doc lub *.pdf definiujących ramy prawne projektu (umów) z możliwością ich umieszczania, znakowania, przechowywania, edycji i usuwania. Powinna znajdować się możliwość sortowania dokumentów wg ich wersji oraz definiowania wersji dodawanego do repozytorium dokumentu. USER_01 UCS_000, UCS_007, UCS_011, UCS_010, UCS_009, UCS_008 RQ_003 Zarządzanie implementacją projektu Kierownik projektu powinien mieć możliwość definiowania za pomocą aplikacji ram czasowych projektu z uwzględnieniem jego struktury i architektury, podziału na pakiety funkcjonalne i ich moduły. Informacje związane z terminami na poszczególne zadania powinny trafiać do programistów. Powiązania: Moduł powinien raportować kierownikowi projektu postępy realizowanych przez programistów prac w odniesieniu do zatwierdzonej specyfikacji wymagań systemowych. Każdy moduł powinien posiadać odpowiednie statusy raportujące o stanie prac programisty nad tym modułem. Zakończenie prac nad modułami składającymi się na dany pakiet powinno być odnotowane i raportowane do kierownika projektu. Ponadto należy sygnalizować przekroczenie terminów zadanych na dany moduł lub pakiet. USER_01, USER_03 UCS_012a, UCS_012b, UCS_012c, UCS_004, UCS_013, UCS_015, UCS_019, UCS_01, UCS_014, UCS_017, UCS_018, UCS_020, UCS_048, UCS_049, UCS_051, UCS_050, UCS_052, UCS_053, UCS_053a, UCS_054 RQ_004 Zapewnienie możliwości zarządzania i kontroli etapu analizy wymagań

29 Powiązania: systemowych Analityk systemowy oraz kierownik projektu powinien mieć możliwość łatwego dostępu do ustrukturalizowanego repozytorium wiedzy dotyczącej dokumentacji wymagań projektowych z wersjonowaniem wprowadzanych dokumentów SWS w formacie *.doc lub *.pdf. USER_01, USER_02 UCS_002, UCS_24, UCS_027, UCS_030, UCS_028, UCS_02, UCS_029 RQ_005 Powiązania: Utworzenie modułu kontroli produktów etapu projektowania systemu Udostępnienie analitykowi systemowemu i kierownikowi projektu oraz programiście repozytorium artefaktów projektowych z podziałem na : - diagramy przypadków użycia - diagramy klas - inne diagramy UML Moduł powinien udostępniać możliwość pełnego zarządzania oraz wersjonowania dokumentów w formacie *.doc lub *.pdf. USER_01, USER_02, USER_03 UCS_003, UCS_025, UCS_031, UCS_034, UCS_053, UCS_032, UCS_035, UCS_03, UCS_037, UCS_038, UCS_053, UCS_040, UCS_041, UCS_042, UCS_043, UCS_044, UCS_045, UCS_054, UCS_047, UCS_053a, RQ_00 Powiązania: Zapewnienie możliwości kontroli procesu wdrożenia zrealizowanego systemu u Klienta Udostępnienie analitykowi systemowemu i kierownikowi projektu oraz programiście repozytorium artefaktów projektowych z podziałem na : - diagramy przypadków użycia - diagramy klas - inne diagramy UML Moduł powinien udostępniać możliwość pełnego zarządzania oraz wersjonowania dokumentów w formacie *.doc lub *.pdf USER_01, USER_02, USER_03 UCS_005, UCS_059, UCS_00, UCS_058, UCS_057, UCS_058 RQ_007 Powiązania: Realizacja modułu wspierającego i dokumentującego proces testowania aplikacji zrealizowanej systemem PM Project Manager Udostępnienie kierownikowi projektu oraz testerowi repozytorium artefaktów wymaganych dla przetestowania stworzonego systemu z możliwością stworzenia repozytorium przypadków testowych z oznaczeniem, które z testów wykonano i które z nich zakończyły się akceptacją przez testera weryfikowanych funkcjonalności. USER_01, USER_04 UCS_00, UCS_021, UCS_022, UCS_023, UCS_022, UCS_055,

30 RQ_008 Powiązania: Umożliwienie Klientowi aplikacji wglądu w postępy prac w zestawieniu z wymaganiami zaakceptowanymi na etapie formułowania umowy Wymaganie dotyczy utworzenia panelu Klienckiego, w którym za pomocą unikatowych danych logowania Klient będzie mieć wgląd w postępy realizacji aplikacji. Forma wglądu ma umożliwiać uwidocznienie postępu prac w zestawieniu z listą wymagań na system, zaakceptowanych dla danego przyrostu systemu. USER_01, USER_04 UCS_00, UCS_021, UCS_022, UCS_023, UCS_022, UCS_055, Wymagania sprzętowe XHRQ_001 Konfiguracja serwera Serwer, na którym uruchomiona może być aplikacja powinien być skonfigurowany wg poniższych wymagań: - zainstalowany Apache w wersji zainstalowany framework Symfony w wersji zainstalowana baza danych MySql - do serwera musi być umożliwiony dostęp poprzez SSH do katalogu root Przewiduje się pracę aplikacji na systemie operacyjnym Linux Debian Serwer główny XHRQ_002 Konfiguracja maszyny klienckiej W celu korzystania z aplikacji wymagany jest komputer z podłączeniem do sieci Internet wyposażony w przeglądarkę internetową (Mozilla Firefox w wersji 5.0 i wyższej, IE w wersji 8.0 i wyższej, Opera, Google Chrome). Komputer kliencki Wymagania bezpieczeństwa SRQ_001 Zapewniona powinna zostać wysoka odporność na ataki kradzieży danych System powinien być odporny na następujące ataki: - SQL Injection zapytanie do bazy danych nie może być przekazywane bezpośrednio poprzez plain-text, ale przez ORM odwzorowaniem obiektoworelacyjnym - wykorzystanie serwera jako spam-sender (aplikacja nie może wysyłać i) - serwer nie może być skonfigurowany jako open-relay (konfiguracja EXIM 4)

31 Serwer główny SRQ_002 Logowanie użytkownika powinno zostać zabezpieczone przed nieautoryzowanym dostępem Algorytm (funkcja skrótu) SHA1 wywoływany powinien być w momencie tworzenia hasła i w momencie każdego logowania. Serwer główny, komputer klienta Rys.8. Wymagany poziom zabezpieczenia logowania do systemu Rys.9. Wymagana funkcja skrótu - logo

32 Wymagania użyteczności i elastyczności EURQ_001 Priorytet: Uruchamianie na dowolnym sprzęcie po stronie klienta Wymagane jest, aby aplikacja dała się uruchomić na dowolnym systemie operacyjnym po stronie użytkownika. EURQ_002 Uruchamianie na najpopularniejszych przeglądarkach Poprawne uruchamianie aplikacji co najmniej na przeglądarkach wymienionych jako 3 najpopularniejsze w rankingu Gemius ze stanu w roku 2011: Wymagania wydajności WQ_001 Obsługa do 100 użytkowników jednocześnie Wymagane jest, aby aplikacja działała stabilnie przy obciążeniu do 100 użytkowników jednocześnie. WQ_002 Szybkość wyświetlania się strony Wyświetlanie się żadnej z podstron nie powinno trwać dłużej niż 3s, poza podstronami zawierającymi uploadery plików do bazy danych.

33 Technologia realizacji 4.1. Framework i język programowania analiza i wybór Prace nad wyborem frameworka poprzedzone zostały badaniem cech każdego z dostępnych frameworków do PHP [34]. Język ten został wybrany ze względu na mnogość dotyczących go rozwiązań Open Source. Rozważanym rozwiązaniem był także ASP.NET [35], jednak ze względu na wysoki koszt rozwiązań przy wykorzystaniu licencji biznesowych przestał być brany pod uwagę. Jedną z wad są m.in. ograniczenia na rozmiar bazy danych przy wykorzystaniu MSSQL Express czy, mimo zezwolenia na wykorzystanie komercyjne aplikacji wytworzonych w Visual Studio Express, brak możliwości korzystania z wtyczek, tworzenia aplikacji dla platform 4-bitowych czy korzystania z funkcji Class Designer. Ważnym ograniczeniem jest mniejsza społeczność dostępna przy rozwiązaniach MS, natomiast wiele frameworków do PHP posiada bogate wsparcie z tego źródła. Ponadto ASP.NET wymaga w graniacach 200% czasu na naukę względem czasu potrzebnego na przyuczenie programisty do frameworków stosowanych do PHP i samego PHP. Zrezygnowano z gotowych systemów typu CMS jak Drupal czy Joomla ze względu na fakt, iż zrealizowane w nich aplikacje wytwarzane są w interfejsach klikalnych i posiadają zbyt dalece posuniętą szablonowość, co prowadzić może do zbyt dużego ujednolicenia i utrudnieniach bądź braku możliwości nadania aplikacji indywidualnego charakteru dokładnie dopasowanego do stawianych wymagań. Wybrany dla realizacji aplikacji PM język PHP jest najszerzej wspierany przez wiele środowisk programistycznych, zastosowany został także do szeregu rozwiązań komercyjnych w World Wide Web, które pracują z powodzeniem nie tylko na rynku polskim (rzucającym się w oczy przykładem jest aplikacja internetowa napisana w PHP pod adresem Poniżej przedstawiono porównanie frameworków wspierających kodowanie skryptów w oparciu o PHP + HTML:

34 Tab.5. Zestawienie dostępnych frameworków wspierających tworzenie aplikacji PHP Framework PHP5 MVC Wiele baz danych ORM Szablony Caching Walidacja Ajax Rozbudowa ne wsparcie Modułowość Ash.MVC x x x x x x x x - x 9 Cake PHP x x x x x x x x x 9 Codeigniter x x x - x x x - x x 8 DIY x x - x x x - x - - ez_components x - x - x x x Fusebox x x x - - x - x - x PHP on TRAX x x x x - - x x - x 7 PHPDevShell x x x x x x - x x x 8 PHPOpenBiz x x x x x - x x x - 7 Prado x x x x x x x x x x 9 QPHP x x x - x - x x x x 7 Seagull x x x x x - x x x x 9 Symfony x x x x x x x x x x 10 WACT x x x - x - x - - x WASP x x - - x - x x x x 7 Yii x x x x x x x x x x 10 Zend x x x x - x x x x x 9 SUMA Objaśnienie tabeli Tab.5. W wierszach zorganizowane są wyniki dla poszczególnych aplikacji, które poddano badaniom. Kolumny zawierają informacje o kryteriach, które zastosowano podczas badań i są to odpowiednio: PHP5 Kryterium informuje czy framework pracuje z najnowszą praktycznie stosowaną wersją PHP (istnieje również wersja, jednak nie jest jeszcze ona w praktyce szeroko stosowana). MVC Kryterium weryfikuje czy framework wspiera realizację wzorca projektowego Model View Controller. Wiele baz danych Kryterium informuje o możliwości pracy z więcej niż 3-ma popularnymi bazami danych. ORM

35 Kryterium informuje czy badany framework umożliwia pracę na tabelach bazy danych tak, jak na obiektach. Tworząc obiekt w kodzie aplikacji programista nie musi posługiwać się zapytaniami SQL, np. SELECT, a operuje na zmapowanych do obiektów tabelach bazy danych. Szablony Kryterium informuje czy dostępne jest korzystanie z szablonów kodu. Caching Kryterium informuje czy automatycznie dokonywana jest prekompilacja kodu PHP, co umożliwia pozbycie się fazy translacji. Walidacja Kryterium informuje czy framework zapewnia wsparcie dla walidacji formularzy. (istnienie klas walidatorów, wyrażeń regularnych dla np. walidacji formatu wprowadzanego adresu e- mail). Ajax Kryterium informuje czy framework ułatwia korzystanie z technologii AJAX (helper, sprawdzenie czy dane żądnie jest żądaniem AJAX owym). Rozbudowane wsparcie Kryterium informuje zakresie dostępu do społeczności projektu, forum twórców, dokumentacji projektu, podręczników i stopnia wsparcia ze strony tych źródeł. Modułowość Kryterium informuje o atrybucie frameworka dotyczącego podziału kodu na logiczne moduły pozwalające prowadzić projekt w danym frameworku w sposób uporządkowany. Jeśli framework cechuje się modułowością ewolucja aplikacji jest mniej kosztowna. Wybór frameworka i uzasadnienie: Dla wytworzenia aplikacji PM wybrany został framework przeznaczony do języka PHP oraz w tym języku wykonany Symfony w wersji 1.4. Uargumentowanie wyboru: - pełna modułowość - wiele gotowych pluginów realizujących podstawy nietrywialnych funkcjonalności np. Captcha czy podstawowe Validatory - intuicyjna realizacja wzorca MVC - wysoka stabilność wytworzonej aplikacji - rozszerzalność przez dowolnego programistę (szkolenie 3-dniowe wystarczy w celu rozpoczęcia pracy w Symfony dla osoby posiadającej znajomość języka PHP) - bardzo szeroki support w zakresie zagadnień instalacji i pracy we frameworku Symfony ze strony otwartej społeczności projektu

36 Architektura aplikacji Implementacja wzorca architektury MVC w Symfony [5] Biorąc za przykład moduł wyświetlający listing podstrony bloga możemy zastanowić się nad zagadnieniem: ile komponentów jest potrzebnych aby to zrobić? Rys.10. Schemat wzorca projektowego Model, View, Controller Rys.7 przedstawia schematyczny przepływ sterowania między poszczególnymi warstwami Model, View, Controller we wzorcu projektowym MVC. Zgodnie ze schematem na rysunku Rys.7. wyodrębnić możemy następujące warstwy: 1. Model layer Database abstraction Data access 2. View layer View Template Layout 3. Controller layer Front controller Action Zdawałoby się, że podział taki zmusza dewelopera aplikacji do każdorazowego angażowania się w tworzenie siedmiu różnych skryptów, kiedy w praktyce chce przecież tylko wyświetlić bloga czy zaimplementować działanie dowolnej innej nowej podstrony aplikacji. Jednak taka

37 struktura w rezultacie sprawia, że tworzenie całości aplikacji staje się prostsze i wydajniejsze szczególnie pod kątem zagadnień utrzymania (maintenance). Front controller i layout są współdzielone przez całą część operacyjną aplikacji, jaką jest warstwa action. Możliwe jest zdefiniowanie wielu controllerów i wielu layout ów, jednak każdorazowo będziemy potrzebować tylko po jednym z każdego z nich. Front controller jest elementem logicznym kluczowym dla architektury MVC i jest generowany przez Symfony w całości. Istotnym ułatwieniem jest fakt, że klasy warstwy bazy danych i dostępu do danych są generowane automatycznie przez framework Moduły systemu z poziomu architektury aplikacji Autorzy Symfony bezpieczeństwo, łatwość modyfikacji i strukturalizację aplikacji zapewnili między innymi strukturą modułową. W odróżnieniu od innych aplikacji, gdzie często dane znajdują się w jednym katalogu głównym, tutaj mamy do czynienia z następującym podziałem katalogów wspólnym dla każdej tworzonej aplikacji: Apps Przechowuje (hostuje) wszystkie składowe aplikacje całego projektu. Tutaj znajdą się wszystkie skrypty napisane w PHP z reguły w plikach tekstowych (czasami razem z kodem HTML lub XHTML) Cache Zawiera pliki tymczasowe projektu generowane automatycznie przez framework Config Katalog zawiera pliki konfiguracyjne projektu, jednym z kluczowych jest ProjectConfigurationClass.php zawierający ścieżkę do instalacji Symfony na maszynie, na której framework pracuje, np. w postaci: C:\\Program Files\\PHP\\symfony\\1.4\\lib/autoload/sfCoreAutoload.class.php Istotnym jest, aby zachować tu odpowiednią kolejność znaków slash i backslash Data Katalog zawiera pliki definiujące strukturę bazy danych (schema.sql oraz fixtures.yml) Lib Zawiera klasy i biblioteki projektu Plugins

38 Zawiera pluginy, o ile takich użyjemy. Standardowo do aplikacji posiadającej formularze służące do podawania np. danych logowania stosujemy plug-in sfcaptchagdplugin. Symfony posiada wiele innych pluginów, ich liczba również ciągle rośnie Test Zawiera testy jednostkowe i funkcjonalne, o ile takie zostały napisane przez zespół developerski Web Katalog główny zawierający przede wszystkim: - kaskadowe arkusze stylów - skrypty JavaScript obsługujące aplikację - pliki graficzne wykorzystane w aplikacji - plik.htaccess tj. plik konfiguracyjny serwera Apache - pliki służące do uruchamiania aplikacji w trybie produkcyjnym i debug z uwidocznieniem błędów index.php i frontend_dev.php Rys. 9 przedstawia strukturę katalogów aplikacji wraz z plikami repozytorium wersjonującego SVN, które zostało użyte w celu umożliwienia zarządzania wersjami pośrednimi aplikacji, a także wykonywania jednocześnie archiwizacji kolejnych rewizji na serwerze oraz na komputerze lokalnym.

39 Rys. 11. Struktura katalogów projektu w Symfony

40 Moduły systemu z poziomu funkcjonalności aplikacji Moduł prawny Moduł realizuje funkcjonalność wspierającą płaszczyznę zagadnień prawnych mających wpływ na realizowany projekt Moduł analityczny Moduł realizuje funkcjonalność wspierającą etap pozyskiwania i analizy wymagań, których spełnienie zagwarantuje zamknięcie realizacji projektu sukcesem Moduł projektowy Moduł realizuje funkcjonalność wspierającą etap projektowania realizowanej aplikacji w zakresie wszystkich warstw wzorca projektowego (model danych, kontroler, interfejs) Moduł implementacji Moduł realizuje funkcjonalność strukturalizacji prac nad aplikacją poprzez podział ich na pakiety, a pakietów na moduły. Moduł posiada wysoki potencjał rozszerzalności w kierunku rozbudowanego mechanizmu alertowania o zagrożeniach dla realizacji projektu w terminie z opcjonalną dystrybucją komunikatów do autorów przyczyn opóźnienia Moduł testowania Moduł wspiera etap testowania aplikacji zarządzając scenariuszami testowymi Moduł wdrożenia Moduł wspiera wdrożenie projektu poprzez zarządzanie wymaganiami na wdrożenie w środowisku docelowym Zastosowany system zarządzania bazami danych i koncepcja struktury danych Dla aplikacji PM został zastosowany system baz danych MySQL [32], który rozwijany jest przez firmę Oracle. Wcześniej przez większość czasu jego tworzeniem zajmowała się szwedzka firma MySQL AB. MySQL AB została kupiona 1 stycznia 2008 roku przez Sun Microsystems, a ten 27 stycznia 2010 roku przez Oracle Wady i zalety MySQL Z punktu widzenia zastosowanego frameworka mamy szeroki wybór serwerów baz danych. Może to być MySQL, PostgreSQL, SQLite lub inny mechanizm kompatybilny z PDO. MySQL tworzony był raczej z myślą o szybkości niż kompatybilności ze standardem SQL przez dłuższy czas MySQL nie obsługiwał nawet transakcji, co było zresztą głównym argumentem przeciwników tego projektu, jednak obecnie obsługuje większą część obecnego standardu ANSI/ISO SQL (tj. SQL:2003). Wprowadza również swoje rozszerzenia i nowe elementy języka. W wersji 5, z której korzystamy dodano m.in. - procedury składowane (ang. stored procedures) obecne od wersji 5.0,

41 wyzwalacze (triggers) obecne od wersji perspektywy (views) - kursory obecne od wersji harmonogram zadań - od wersji 5.1 MySQL zawiera wsparcie dla replikacji bazy danych i wielojęzyczności każda tabela, a nawet każde pole może mieć własne ustawienie kodowania znaków, co w połączeniu z i18n tj. zunifikowanym mechanizmem obsługi różnych języków w aplikacjach budowanych na frameworku Symfony, daje możliwości dowolnej rozbudowy programu o kolejne języki i możliwość tym samym dotarcia z tworzoną aplikacją do szerszego grona użytkowników. W celu dodania nowego języka, w jakim działać ma aplikacja wystarczy jednorazowo ująć wszystkie tłumaczone napisy w format: ( tłumaczony napis ) dodając uprzednio w nagłówku pliku zapis równoznaczny funkcji require_once dołączający treść funkcji pomocniczych obsługujących również pozostałe zagadnienia związane z wielokulturowością, walutą, wyświetlaniem znaków charakterystycznych dla danych państw i temu podobne: <?php use_helper("i18n")?> Platformy, dla których dostępny jest MySQL Serwer MySQL dostępny jest dla wszystkich popularnych platform systemowych i różnych architektur procesorów. Jest dostępny także w wersji źródłowej, co umożliwia skompilowanie go dla dowolnej innej platformy. Oficjalnie oferowane są wersje binarne dla następujących platform i architektur (MySQL 4.1): Linux (x8, S/390, IA4 (Itanium), Alpha, PowerPC, AMD4 / EM4T), - Windows (x8, x4), - Solaris (SPARC, x8), - FreeBSD (x8), - MacOS X, - HP-UX (PA-RISC IA4), - AIX (RS000), - 15/OS (IBM System I), - QNX (x8), - Novell NetWare (x8), - SGI, - DEC OSF. Platformą, na której uruchomimy bazę danych związaną z PM będzie MS Windows x8, 32- bit.

42 Zastosowanie w PM Wraz z serwerem Apache i parserem PHP, MySql stanowi popularne środowisko serwerowe, które również podczas implementacji PM będzie podstawą całego środowiska. Framework Symfony jednoznacznie definiuje i upraszcza sposób połączenia z bazą danych. Aby je ustanowić wystarczy w pliku database.yml podać poniższe instrukcje z odpowiednimi parametrami: all: doctrine: class: sfdoctrinedatabase param: dsn: 'mysql:host=nazwa_hosta_np_localhost;dbname=tutaj_wpisać_należy_nazwę_bazydanych' username: tu_nazwa_katalogu_głównego password: tutaj_hasło Narzędzia administracyjne dostępne do MySql - phpmyadmin - za pomocą przeglądarki internetowej - MySQL Administrator - MySQL Query Browser Jedynym i zarazem wystarczającym narzędziem do pełnej administracji bazą danych będzie w naszym przypadku MySql Administrator, który pozwoli nam na korzystanie z instrukcji języka SQL oraz w razie potrzeby dostęp do bazy przez intuicyjne GUI Koncepcja struktury danych Miejsce przechowywania danych Pliki danych przechowywane będą na dysku (jak np. obrazki), w samej zaś bazie danych znajdować się będą referencje do ich lokalizacji Diagramy UML Aktorzy USER_01 Typ aktora Opis systemowy Kierownik projektu Aktor ożywiony, wewnętrzny, bezpośrednio korzysta z interfejsu aplikacji Aktor ożywiony posiadający w aplikacji i w prowadzonym za jej pomocą projekcie wytwarzania oprogramowania wgląd i uprawnienia administracyjne w największej ilości modułów systemu. Dostęp do modułu prawnego daje kierownikowi projektu uprawnienia zarządzania umowami definiującymi ramy prawne prowadzonego projektu. Dostęp do modułu implementacji pozwala kierownikowi projektu sprawdzać postępy prac zespołu programistycznego (USER_03). Dostęp do modułu kontroli testowania pozwala zarządzać dokumentami związanymi z testowaniem przeznaczonymi dla testerów projektu (USER_04). Dostęp do modułu wdrożenia pozwala na zarządzanie dokumentami dotyczącymi wdrożenia aplikacji w środowisku Klienta. W module projektowym i analitycznym kierownik projektu posiada pełne uprawnienia edycji, usuwania i dodawania dokumentów, w takim samym

43 Opis biznesowy stopniu, co analityk systemowy (USER_02). Aktor pracujący po stronie wykonawcy wytwarzanej aplikacji, osoba sterująca wytwarzaniem aplikacji na najwyższym poziomie abstrakcji, nie dysponuje wiedzą na temat szczegółowej struktury kodu źródłowego. Zna technologię, architekturę i język programowania zastosowany do wytwarzania aplikacji oraz jego cechy i właściwości. USER_02 Typ aktora Opis systemowy Opis biznesowy Analityk systemowy Aktor ożywiony, wewnętrzny, bezpośrednio korzysta z interfejsu aplikacji Aktor posiada administracyjne uprawnienia w module analitycznym oraz w module projektowym. Dostęp do tych modułów pozwala na wersjonowany dostęp do repozytorium plików pokrywających wymagania projektowe wytwarzanej aplikacji. Aktor pracujący po stronie wykonawcy wytwarzanej aplikacji. Jego głównym zadaniem jest tworzenie i umieszczanie dokumentów analitycznych i projektowych w systemie PM w modułach: analityczny i projektowy, z których korzystać będą programiści (USER_03). USER_03 Typ aktora Opis systemowy Opis biznesowy Programista Aktor ożywiony, wewnętrzny, bezpośrednio korzysta z interfejsu aplikacji Aktor korzysta z modułu implementacji w zakresie zapewniania informacji o postępach prac nad konkretnymi modułami wytwarzanej aplikacji i ich funkcjami. Aktor korzysta z modułu analitycznego w zakresie przeglądania wyników prac analityka systemowego w postaci odpowiednich dokumentów projektowych będących dla Programisty pomocą i podstawą do tworzenia kodu źródłowego wytwarzanej aplikacji. Aktor korzysta z modułu wdrożenia w zakresie przeglądania specyfikacji wdrożenia i dodania raportu z wdrożenia po jego wykonaniu. Aktor pracujący po stronie wykonawcy wytwarzanej aplikacji. Tworzy kod źródłowy na podstawie dokumentów projektowych pochodzących z etapu projektowania (moduł projektowania). USER_04 Typ aktora Opis systemowy Opis biznesowy Tester Aktor ożywiony, bezpośrednio korzysta z interfejsu aplikacji Aktor korzysta z modułu testowania z uprawnieniami do wyświetlania scenariuszy testowych i oznaczania, że są one zrealizowane poprawnie przez wytwarzaną aplikację. Aktor pracujący po stronie wykonawcy wytwarzanej aplikacji. Obsługuje moduł testowy w zakresie przeprowadzania pobranych z niego scenariuszy testowych USER_05 Typ aktora Opis systemowy Opis biznesowy Klient Aktor ożywiony, zewnętrzny, bezpośrednio korzysta z interfejsu aplikacji Aktor zewnętrzny posiadający dostęp do modułu prezentacji wyników prac na wszystkich etapach wytwarzania. Aktor pracujący po stronie Zamawiającego (Klienta) wytwarzanej aplikacji. W wersji 1.0 aplikacji PM reprezentuje Klienta jako podmiot zlecający usługę realizacji aplikacji dedykowanej na indywidualne zamówienie.

44 Uprawnienia aktorów z podziałem na moduły USER_01 Kierownik projektu USER_02 Analityk systemowy USER_03 Programista USER_04 Tester USER_05 Klient Moduł prawny ADM Moduł analityczny ADM ADM - RO SPEC Moduł projektowy ADM ADM RO - - Moduł implementacji ADM - SPEC RO SPEC Moduł testowania ADM - - SPEC - Moduł wdrożenia ADM SPEC RO RO - ADM pełne uprawnienia, dodawania, usuwania, edycji artefaktów RO uprawnienia ograniczone do odczytu artefaktów SPEC uprawnienia specjalne konfigurowane indywidualnie dla danej roli

45 Diagramy przypadków użycia USER_01 Kierownik projektu Rys. 12. Diagram przypadków użycia USER_01_moduł_analityczny Rys. 13. Diagram przypadków użycia USER_01_moduł_kontroli_implementacji

46 - 4 - Rys. 14. Diagram przypadków użycia USER_01_ moduł_kontroli_testowania Rys. 15. Diagram przypadków użycia USER_01_ moduł_prawny

47 Rys. 1. Diagram przypadków użycia USER_01_moduł_projektowy Rys. 17. Diagram przypadków użycia USER_01_moduł_wdrożenia Diagram zbiorczy dla USER_01 znajduje się w załączniku all_user_01_kierownik_projektu_use_cases.png.

48 USER_02 Analityk systemowy Rys. 18. Diagram przypadków użycia USER_02_moduł_analityczny Rys. 19. Diagram przypadków użycia USER_02_moduł_projektowy Diagram zbiorczy dla USER_02 w załączniku all_user_02_use_cases.png.

49 USER_03 Programista Rys. 20. Diagram przypadków użycia USER_03_moduł_kontroli_implementacji Rys. 21. Diagram przypadków użycia USER_03_moduł_kontroli_wdrożenia Rys. 22. Diagram przypadków użycia USER_03_moduł_projektowy Diagram zbiorczy dla USER_02 w załączniku all_user_03_use_cases.png.

50 USER_04 Tester diagram kompletny Rys. 23. Diagram przypadków użycia USER_04_moduł_kontroli testowania USER_05 Klient diagram kompletny Rys. 24. Diagram przypadków użycia USER_05_przeglądanie_wyników_prac Opisy diagramów przypadków użycia Przypadki użycia dla USER_01_kierownik projektu Opis zawiera słowne przedstawienie szczegółów przypadku użycia. Dotyczy specyfikuje aktora, który realizuje przypadek użycia. Priorytet 1 realizuje fundamentalne funkcje wersji 1.0, 2 realizuje funkcje addytywne wersji 1.0 lub wersji 1.1. Powiązany jeśli to konieczne do kompleksowego zrozumienia działania systemu zawiera numer przypadku użycia powiązanego z danym przypadkiem użycia. Moduł prawny UCS_000 Wybór projektu Wybór projektu to współdzielony przypadek wszystkich aktorów w aplikacji PM z wyłączeniem USER_05. Pracownicy po stronie wykonawcy (USER 01 04) przed uzyskaniem dostępu do wyboru modułów, z których mogą korzystać

51 wybierają aplikację, nad wytwarzaniem której aktualnie pracują. Przypadek użycia UCS_000 pozwala na dokonanie tego wyboru. Wybór dokonywany jest po nazwie roboczej projektu zamieszczonej wcześniej w systemie przez kierownika projektu. USER_01 Kierownik projektu USER_01_UCS_001, USER_01_UCS_002, USER_01_UCS_003, USER_01_UCS_004, USER_01_UCS_005, USER_01_UCS_00, USER_02, USER_03, USER_04 UCS_001 Korzystanie z modułu prawnego Przypadek ten umożliwia kierownikowi projektu korzystanie z modułu pomagającego zorganizować, usystematyzować i przechowywać informacje o ramach prawnych wykonywanego projektu. Może zawierać dzienniki ustaw, umowy, opisy standardów. USER_01 Kierownik projektu USER_01_UCS_000, USER_01_UCS_007 UCS_007 Zarządzanie umowami Przypadek ten zintegrowany jest z modułem prawnym i umożliwia przeglądanie w odpowiednich wersjach, dodawanie i usuwanie umów. USER_01 Kierownik projektu USER_01_UCS_001, USER_01_UCS_008, USER_01_UCS_009, USER_01_UCS_010 UCS_008 Dodanie umowy Przypadek umożliwia dodanie nowej wersji umowy. USER_01 Kierownik projektu USER_01_UCS_007, USER_01_UCS_009, USER_01_UCS_010, USER_01_UCS_011, USER_01_UCS_012 UCS_009 Wyświetlenie wszystkich wersji umowy Przypadek umożliwia wyświetlenie wszystkich wersji umowy oraz sortowanie. USER_01 Kierownik projektu USER_01_UCS_007, USER_01_UCS_012

52 UCS_010 Usunięcie umowy Przypadek umożliwia kierownikowi projektu usunięcie niepotrzebnych wersji umowy ze spisu wersji umów w module prawnym. USER_01 Kierownik projektu USER_01_UCS_007 UCS_011 Definicja wersji umowy Przypadek następujący jako wymagane następstwo przypadku UCS_008 Dodanie umowy. Następuje tu nadanie umowie wersji wg. ustalonej nomenklatury pozwalającej w okresie późniejszym zidentyfikować potrzebne parametry umowy. USER_01 Kierownik projektu USER_01_UCS_008 UCS_012 Wyświetlenie najnowszej wersji umowy Przypadek umożliwia szybkie odnalezienie wersji umowy na wykonanie projektu, która jest najbardziej aktualna. USER_01 Kierownik projektu USER_01_UCS_009 UCS_012a Dodanie projektu Przypadek dostępny tylko dla kierownika projektu, umożliwiający kierownikowi projektu zdefiniowanie nowego projektu, który prowadzony będzie za pomocą aplikacji PM. USER_01 Kierownik projektu USER_01_UCS_009 UCS_012b Zaznaczenie projektu jako zrealizowany w całości Przypadek pozwalający na pozytywne zamknięcie projektu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_012c Usunięcie projektu z podaniem przyczyn Przypadek pozwalający na negatywne zamknięcie projektu.

53 USER_01 Kierownik projektu USER_01_UCS_009 Moduł analityczny UCS_002 Korzystanie z modułu analitycznego Przypadek umożliwia korzystanie z modułu znajdującego zastosowanie wraz z wkroczeniem prowadzonego projektu w 1. fazę cyklu kaskadowego fazę analizy. USER_01 Kierownik projektu USER_01_UCS_009 UCS_24 Zarządzanie specyfikacją wymagań Przypadek umożliwia zarządzanie wymaganiami na system poprzez udostępnienie repozytorium odpowiednich dla etapu analizy artefaktów. USER_01 Kierownik projektu USER_01_UCS_009 UCS_027 Wyświetlenie listy wersji specyfikacji wymagań Przypadek umożliwia przeglądanie wszystkich wersji specyfikacji wymagań, jakie się pojawiają z możliwością ich prostego wersjonowania oraz sortowania. Następuje tu nadanie specyfikacji wersji wg. ustalonej nomenklatury pozwalającej w okresie późniejszym zidentyfikować potrzebne parametry specyfikacji. USER_01 Kierownik projektu USER_01_UCS_009 UCS_030 Wyświetlenie najnowszej wersji specyfikacji wymagań Przypadek umożliwia szybkie znalezienie najbardziej aktualnej wersji specyfikacji wymagań. USER_01 Kierownik projektu USER_01_UCS_009 UCS_028 Usunięcie specyfikacji wymagań Przypadek umożliwia usunięcie zbędnych wersji specyfikacji wymagań. Możliwe jest usunięcie jednej specyfikacji bądź kilku wersji jednocześnie.

54 USER_01 Kierownik projektu USER_01_UCS_009 UCS_02 Dodanie specyfikacji wymagań Przypadek umożliwia kierownikowi projektu dodanie nowej specyfikacji wymagań lub nowej wersji poprzednio już dodanej specyfikacji. USER_01 Kierownik projektu USER_01_UCS_009 UCS_029 Określenie wersji specyfikacji wymagań Przypadek następujący jako wymagane następstwo przypadku UCS_02 Dodanie specyfikacji wymagań. Następuje tu nadanie specyfikacji wersji wg. ustalonej nomenklatury pozwalającej w okresie późniejszym zidentyfikować potrzebne parametry specyfikacji. USER_01 Kierownik projektu USER_01_UCS_009 Moduł projektowy UCS_003 Korzystanie z modułu projektowego Przypadek umożliwia korzystanie z modułu znajdującego zastosowanie wraz z wkroczeniem prowadzonego projektu w 2. fazę cyklu kaskadowego fazę projektu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_025 Zarządzanie artefaktami projektowymi Przypadek umożliwia dostęp do repozytorium oraz modułu zarządzania wszelkimi artefaktami mogącymi mieć zastosowanie na etapie projektu systemu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_031 Zarządzanie diagramami przypadków użycia Przypadek umożliwia zarządzanie diagramami UML obrazującymi funkcjonalne punkty styku systemowych użytkowników końcowych z tworzonym systemem. Kierownik projektu ma dostęp do diagramów UML, które mogą być podstawą i

55 płaszczyzną dyskusji precyzujących funkcjonalność realizowanego systemu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_034 Dodanie diagramu przypadków użycia Przypadek umożliwia dodanie nowego diagramu UML zawierającego przypadki użycia systemu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_053 Wyświetlenie wszystkich wersji diagramu przypadków użycia Przypadek umożliwia przeglądanie wszystkich wersji diagramów przypadków użycia, jakie mają zastosowanie na etapie projektowania z możliwością ich wersjonowania oraz sortowania. Następuje tu nadanie diagramom wersji wg. ustalonej nomenklatury pozwalającej w okresie późniejszym zidentyfikować potrzebne parametry dokumentu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_032 Wyświetlenie najnowszej wersji diagramu przypadków użycia Przypadek umożliwia szybkie znalezienie najbardziej aktualnej wersji diagramu przypadków użycia. USER_01 Kierownik projektu USER_01_UCS_009 UCS_035 Usunięcie diagramu przypadków użycia Przypadek umożliwia usunięcie wybranego diagramu przypadków użycia. Możliwe jest usunięcie jednego lub większej ilości diagramów jednocześnie. USER_01 Kierownik projektu USER_01_UCS_009 UCS_3 Zarządzanie diagramami klas Przypadek umożliwia dostęp do repozytorium i modułu zarządzania diagramami klas.

56 - 5 - USER_01 Kierownik projektu USER_01_UCS_009 UCS_037 Dodanie diagramu klas Przypadek umożliwia dodanie nowego diagramu klas systemu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_038 Określenie wersji diagramu klas Przypadek jest wymagany do zrealizowania przy dodawaniu nowego diagramu klas (UCS_037). Pozwala w okresie późniejszym na ewidencjonowanie wersji dodanych diagramów klas. USER_01 Kierownik projektu USER_01_UCS_009 UCS_053 Wyświetlenie listy wersji diagramu klas Przypadek umożliwia przeglądanie wszystkich wprowadzonych dla danego systemu w etapie projektowania diagramów klas. USER_01 Kierownik projektu USER_01_UCS_009 UCS_040 Wyświetlenie najnowszej wersji diagramu klas Przypadek umożliwia szybkie znalezienie najbardziej aktualnej wersji spośród wprowadzonych do aplikacji PM diagramów klas. USER_01 Kierownik projektu USER_01_UCS_009 UCS_041 Usunięcie diagramu klas Przypadek umożliwia usunięcie wybranego diagramu klas z modułu zarządzania artefaktami projektowymi. Możliwe jest jednoczesne usunięcie więcej niż jednej wersji modułu klas. USER_01 Kierownik projektu USER_01_UCS_009

57 UCS_042 Zarządzanie pozostałymi diagramami UML Przypadek umożliwia kierownikowi projektu dostęp do repozytorium i modułu zarządzania takimi artefaktami jak: - diagramy stanów - diagramy czynności - diagramy kooperacji - diagramy sekwencji - diagramy koncepcji struktury danych - diagramy pakietów - diagramy architektury - dokumenty uzupełniające - dokumenty zawierające opisy powyższych USER_01 Kierownik projektu USER_01_UCS_009 UCS_043 Dodanie innego diagramu UML Przypadek umożliwia kierownikowi projektu dodanie do systemu PM diagramu UML innego typu, niż diagram przypadków użycia oraz diagram klas w celu uzupełnienia odzwierciedlenia działania systemu względem osi czasu, stanu obiektów, architektury i innych obszarów uzupełniających. USER_01 Kierownik projektu USER_01_UCS_009 UCS_044 Wybór rodzaju diagramu Pozostający w relacji <<include>> z UCS_043 przypadek umożliwia określenie rodzaju innego diagram, który dodawany jest poprzez przypadek użycia UCS_043. USER_01 Kierownik projektu USER_01_UCS_009 UCS_045 Określenie wersji diagramu innego typu Pozostający w relacji <<include>> z UCS_044 przypadek pozwalający na nadanie dokumentowi innego typu o określonym wcześniej typie wersji, w której zostanie umieszczony w repozytorium. USER_01 Kierownik projektu USER_01_UCS_009 UCS_054 Wyświetlenie listy innych diagramów UML

58 Przypadek umożliwia przeglądanie listy wszystkich wersji wszystkich wprowadzonych typów diagramów innych niż diagramy przypadków użycia i klas z możliwością sortowania wg odpowiednich kryteriów. USER_01 Kierownik projektu USER_01_UCS_009 UCS_047 Usunięcie innego diagramu UML Przypadek pozwala na usunięcie z aplikacji PM wybranego z listy diagramu innego niż diagram klas i diagram przypadków użycia (diagramu innego typu). USER_01 Kierownik projektu USER_01_UCS_009 Moduł kontroli implementacji UCS_004 Korzystanie z modułu kontroli implementacji Przypadek umożliwia korzystanie z modułu znajdującego zastosowanie wraz z wkroczeniem prowadzonego projektu w 3. fazę cyklu kaskadowego fazę implementacji. USER_01 Kierownik projektu USER_01_UCS_009 UCS_013 Zarządzanie realizacją pakietów Przypadek umożliwia kontrolę stanu realizacji pakietów implementowanego systemu informatycznego dla strony Zamawiającej. USER_01 Kierownik projektu USER_01_UCS_009 UCS_015 Dodanie pakietu Przypadek umożliwia dodanie i opisanie pakietu jako podstawowej składowej realizowanego systemu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_019 Wyznaczenie terminu na pakiet Przypadek umożliwia nadanie (zaplanowanie) pakietowi horyzontu czasowego

59 do wykonania, który widoczny będzie dla programistów i testerów realizowanego systemu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_01 Usunięcie pakietu Przypadek umożliwia usunięcie pakietu realizowanego systemu. Usuwana zostaje informacja o pakiecie, a nie sam pakiet. USER_01 Kierownik projektu USER_01_UCS_009 UCS_014 Zarządzanie realizacją modułów Przypadek umożliwia zarządzanie zawartością pakietu tj. modułami tego pakietu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_017 Dodanie modułów Przypadek umożliwia dodanie do dodanego wcześniej pakietu listy modułów tego pakietu. Moduł traktowany jest jako składową pakietu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_018 Usunięcie modułu Przypadek umożliwia usunięcie jednego lub więcej modułów jednocześnie z danego pakietu. USER_01 Kierownik projektu USER_01_UCS_009 UCS_020 Wyznaczenie terminu na moduł Przypadek umożliwia zdefiniowanie terminu realizacji dla każdego modułu z osobna. USER_01 Kierownik projektu

60 - 0 - USER_01_UCS_009 Moduł kontroli wdrożenia UCS_005 Korzystanie z modułu kontroli wdrożenia Przypadek umożliwia korzystanie z modułu znajdującego zastosowanie wraz z wkroczeniem prowadzonego projektu w 4. fazę cyklu kaskadowego fazę wdrożenia. USER_01 Kierownik projektu USER_01_UCS_009 UCS_059 Dodanie specyfikacji wdrożenia Przypadek umożliwia dodanie do systemu PM przez kierownika projektu dokumentu zawierającego wytyczne dla programistów dotyczące sposobu migracji aplikacji ze środowiska developerskiego do środowiska docelowego. USER_01 Kierownik projektu USER_01_UCS_009 UCS_00 Usunięcie dokumentu wdrożenia Przypadek umożliwia usunięcie dokumentu wdrożenia z systemu PM. USER_01 Kierownik projektu USER_01_UCS_009 UCS_058 Przeglądanie specyfikacji wdrożenia Przypadek umożliwia wyświetlenie wcześniej dodanego dokumentu wdrożenia w celu jego edycji i ponownego zapisu w systemie bądź w celu wydruku. USER_01 Kierownik projektu USER_01_UCS_009 UCS_01 Przeglądanie raportu z wdrożenia Przypadek umożliwia wyświetlenie i zapoznanie się przez kierownika projektu z raportem z wdrożenia wykonanym przez programistów. USER_01 Kierownik projektu USER_01_UCS_009

61 - 1 - Moduł kontroli testowania UCS_00 Korzystanie z modułu kontroli testowania Przypadek umożliwia korzystanie z modułu znajdującego zastosowanie wraz z wkroczeniem prowadzonego projektu w 5. fazę cyklu kaskadowego fazę testowania. USER_01 Kierownik projektu USER_01_UCS_009 UCS_021 Dodanie scenariusza testowego Przypadek umożliwia dodanie przez kierownika projektu do systemu PM scenariusza testowego realizowanej dla Klienta aplikacji. USER_01 Kierownik projektu USER_01_UCS_009 UCS_022 Wyświetlenie listy scenariuszy testowych Przypadek umożliwia przeglądanie listy wszystkich scenariuszy testowych systemu realizowanego dla Klienta. USER_01 Kierownik projektu USER_01_UCS_009 UCS_023 Usunięcie scenariusza testowego Przypadek umożliwia usunięcie wybranego scenariusza testowego. USER_01 Kierownik projektu USER_01_UCS_ Przypadki użycia dla USER_02_analityk systemowy Moduł analityczny UCS_002 Korzystanie z modułu analitycznego Przypadek umożliwia korzystanie z modułu analitycznego przez analityka systemowego w celu prowadzenia czynności mających na celu utworzenie, ujednolicenie, doprecyzowanie i skonkretyzowanie specyfikacji wymagań definiującej ramy funkcjonalne systemu realizowanego przez zespół projektowy dla Klienta. Analityk korzysta z modułu analitycznego z uprawnieniami administratora.

62 - 2 - USER_02_Analityk systemowy USER_02_UCS_000, USER_02_UCS_024 UCS_024 Zarządzanie specyfikacją wymagań Przypadek umożliwia zarządzanie specyfikacją wymagań na realizowany dla Klienta system przez analityka systemowego. USER_02_Analityk systemowy USER_02_UCS_002, USER_02_UCS_02, USER_02_UCS_027, USER_02_UCS_028 UCS_02 Dodanie specyfikacji wymagań Przypadek umożliwia dodanie przez analityka systemowego specyfikacji wymagań systemu realizowanego dla Klienta. USER_02_Analityk systemowy USER_02_UCS_024, USER_02_UCS_029 UCS_029 Określenie wersji specyfikacji wymagań Przypadek pozostający w relacji <<include>> z UCS_02. Przypadek realizuje zdefiniowanie wersji specyfikacji wymagań przez analityka podczas jej dodawania do systemu PM. USER_02_Analityk systemowy USER_01_UCS_02 UCS_030 Wyświetlenie najnowszej wersji specyfikacji wymagań Przypadek umożliwia szybkie znalezienie najbardziej aktualnej wersji diagramu przypadków użycia przez analityka systemowego. USER_02_Analityk systemowy USER_02_UCS_027 UCS_027 Wyświetlenie listy wersji specyfikacji wymagań Przypadek umożliwia przeglądanie przez analityka systemowego wszystkich wersji specyfikacji wymagań, jakie się pojawiają z możliwością ich łatwego wersjonowania oraz sortowania. Następuje tu nadanie specyfikacji wersji wg. ustalonej nomenklatury pozwalającej w okresie późniejszym zidentyfikować potrzebne parametry specyfikacji.

63 - 3 - USER_02_Analityk systemowy USER_01_UCS_024, USER_02_UCS_030 UCS_028 Usunięcie specyfikacji wymagań Przypadek umożliwia zaznaczenie i usunięcie jednej bądź wielu wersji specyfikacji wymagań. USER_02 Analityk systemowy USER_01_UCS_024 Korzystanie z modułu projektowego UCS_003 Korzystanie z modułu projektowego Przypadek umożliwia korzystanie przez analityka z modułu projektowego z uprawnieniami administratora. USER_02_Analityk systemowy USER_02_UCS_000, USER_02_UCS_025 UCS_025 Zarządzanie artefaktami projektowymi Przypadek umożliwia przeglądanie panelu zarządzania artefaktami projektowymi przez analityka systemowego i wybór dalszych opcji. USER_02_Analityk systemowy USER_02_UCS_003, USER_02_UCS_031, USER_02_UCS_03, USER_02_UCS_042 UCS_032 Wyświetlenie najnowszej wersji diagramu przypadków użycia Przypadek umożliwia szybkie wyszukanie i podgląd najbardziej aktualnej wersji diagramu przypadków użycia. USER_02_Analityk systemowy USER_02_UCS_031 UCS_053 Wyświetlenie wszystkich wersji diagramu przypadków użycia Przypadek umożliwia podgląd diagramów przypadków użycia we wszystkich umieszczonych w systemie wersjach. USER_02_Analityk systemowy

64 - 4 - USER_02_UCS_031 UCS_034 Dodanie diagramu przypadków użycia Przypadek umożliwia dodanie nowego diagramu przypadków użycia do systemu. USER_02_Analityk systemowy USER_02_UCS_031 UCS_035 Usunięcie diagramu przypadków użycia Przypadek umożliwia usunięcie wybranej wersji diagramu przypadków użycia realizowanego systemu z systemu PM. USER_02_Analityk systemowy USER_02_UCS_031 UCS_031 Zarządzanie diagramami przypadków użycia Przypadek umożliwia zarządzanie przez analityka systemowego diagramami UML obrazującymi funkcjonalne punkty styku systemowych użytkowników końcowych z tworzonym systemem. Kierownik projektu ma dostęp do diagramów UML, które mogą być podstawą i płaszczyzną dyskusji precyzujących funkcjonalność realizowanego systemu. USER_02_Analityk systemowy USER_02_UCS_025, USER_02_UCS_032, USER_02_UCS_053, USER_02_UCS_034, USER_02_UCS_035 UCS_03 Zarządzanie diagramami klas Przypadek umożliwia analitykowi systemowemu dostęp do repozytorium i modułu zarządzania diagramami klas. USER_02_Analityk systemowy USER_02_UCS_025, USER_02_UCS_037, USER_02_UCS_053a, USER_02_UCS_041 UCS_037 Dodanie diagramu klas Przypadek umożliwia dodanie nowego diagramu klas do systemu PM przez analityka systemowego. USER_02_Analityk systemowy

65 - 5 - USER_02_UCS_038, USER_02_UCS_03 UCS_038 Określenie wersji diagramu klas Przypadek w relacji <<include>> z UCS_037 umożliwiający podanie wersji w jakiej dodany do systemu PM zostanie diagram klas. USER_02_Analityk systemowy USER_01_UCS_037 UCS_040 Wyświetlenie najnowszej wersji diagramu klas Umożliwia szybkie wyszukanie najbardziej aktualnej wersji diagramu klas. USER_02_Analityk systemowy USER_01_UCS_053a UCS_053a Wyświetlenie listy wersji diagramu klas Umożliwia analitykowi przegląd wszystkich wprowadzonych wcześniej do systemu wersji diagramu klas realizowanego dla Klienta systemu. USER_02_Analityk systemowy USER_01_UCS_03, USER_01_UCS_040 UCS_041 Usunięcie diagramu klas Przypadek umożliwia usunięcie przez analityka systemowego z systemu PM wybranej wersji diagramu klas. Można także jednocześnie usunąć więcej niż jedną wersję diagramu klas. USER_02_Analityk systemowy USER_01_UCS_03 UCS_042 Zarządzanie pozostałymi diagramami UML Przypadek umożliwia analitykowi systemowego dostęp do repozytorium i modułu zarządzania takimi artefaktami jak: - diagramy stanów - diagramy czynności - diagramy kooperacji - diagramy sekwencji - diagramy koncepcji struktury danych - diagramy pakietów - diagramy architektury - dokumenty uzupełniające - dokumenty zawierające opisy powyższych

66 - - USER_02_Analityk systemowy USER_01_UCS_025, USER_01_UCS_043, USER_01_UCS_054, USER_01_UCS_047 UCS_043 Dodanie innego diagramu UML Przypadek umożliwia analitykowi systemowemu dodanie do systemu PM diagramu UML innego typu, niż diagram przypadków użycia oraz diagram klas w celu uzupełnienia odzwierciedlenia działania systemu względem osi czasu, stanu obiektów, architektury i innych obszarów uzupełniających. USER_02_Analityk systemowy USER_01_UCS_042, USER_01_UCS_044 UCS_044 Wybór rodzaju diagramu Pozostający w relacji <<include>> z UCS_043 przypadek umożliwia określenie rodzaju innego diagramu, który dodawany jest przez analityka systemowego poprzez przypadek użycia UCS_043. USER_02_Analityk systemowy USER_01_UCS_043, USER_01_UCS_045 UCS_045 Określenie wersji diagramu Przypadek użycia w relacji <<include>> z UCS_037 występujący przy dodawaniu nowego diagramu klas przez analityka systemowego. Pozwala w okresie późniejszym na ewidencjonowanie wersji dodanych diagramów klas. USER_02_Analityk systemowy USER_01_UCS_044 UCS_054 Wyświetlenie listy innych diagramów UML Przypadek umożliwia przeglądanie przez analityka systemowego listy wszystkich wersji wszystkich wprowadzonych typów diagramów innych niż diagramy przypadków użycia i klas z możliwością sortowania wg odpowiednich kryteriów. USER_02_Analityk systemowy USER_01_UCS_042 UCS_047 Usunięcie innego diagramu UML

67 - 7 - Przypadek umożliwia usunięcie wybranej wersji diagramu UML z systemu PM przez analityka systemowego. USER_02_Analityk systemowy USER_01_UCS_ Przypadki użycia dla USER_03_programista UCS_000 Wybór projektu Przypadek umożliwia wybór projektu, w którym programista chce raportować postępy prac implementacyjnych i wdrożeniowych. USER_03_programista USER_03_UCS_004, USER_03_UCS_003, USER_03_UCS_005 UCS_004 Korzystanie z modułu kontroli implementacji Przypadek umożliwia programiście wprowadzanie danych dotyczących postępów w implementowanym systemie do modułu kontroli postępów prac. USER_03_programista USER_03_UCS_000, USER_03_UCS_048 UCS_003 Korzystanie z modułu projektowego Przypadek umożliwia programiście korzystanie z modułu zawierającego artefakty projektowe wytworzone we wcześniejszych etapach cyklu wytwarzania oprogramowania. USER_03_programista USER_03_UCS_052, USER_03_UCS_000 UCS_005 Korzystanie z modułu kontroli wdrożenia Przypadek umożliwia programiście podawanie i pobieranie informacji dotyczących wdrożenia umożliwiając jego sformalizowany i kontrolowany przebieg. USER_03_programista USER_03_UCS_000, USER_03_UCS_57, USER_03_UCS_058 UCS_048 Wyświetlenie listy pakietów

68 - 8 - Przypadek umożliwia programiście wylistowanie pakietów, które składają się na implementowany system. USER_03_programista USER_03_UCS_004, USER_03_UCS_049 UCS_049 Wyświetlenie listy modułów pakietu Przypadek umożliwia programiście wylistowanie modułów, na które składa się wybrany pakiet implementowanego oprogramowania. USER_03_programista USER_03_UCS_48, USER_03_UCS_50, USER_03_UCS_51 UCS_051 Zaznaczenie modułu jako w trakcie realizacji Przypadek umożliwia programiście przekazanie do systemu PM informacji o podjęciu realizacji wybranego modułu. USER_03_programista USER_03_UCS_049 UCS_050 Zaznaczenie modułu jako wykonany Przypadek umożliwia programiście przekazanie do systemu PM informacji o pozytywnym zakończeniu prac nad wybranym modułem oprogramowania. USER_03_programista USER_03_UCS_049 UCS_052 Przeglądanie artefaktów projektowych Przypadek umożliwia programiście przeglądanie elementów wytworzonych przez analityków oraz kierownika projektu na etapie projektowania systemu. USER_03_programista USER_03_UCS_53, USER_03_UCS_53a, USER_03_UCS_54, USER_03_UCS_003 UCS_053 Wyświetlenie wszystkich wersji diagramu przypadków użycia Przypadek umożliwia programiście przeglądanie listy wersji diagramu przypadków użycia implementowanego systemu dodanych uprzednio do systemu PM przez kierownika projektu lub analityka systemowego.

69 - 9 - USER_03_programista USER_03_UCS_52 UCS_053a Wyświetlenie listy wersji diagramu klas Przypadek umożliwia programiście przeglądanie listy diagramów klas z uwzględnieniem ich wersji. Diagramy te zostały wcześniej dodane do systemu PM przez kierownika projektu lub analityka systemowego. USER_03_programista USER_03_UCS_052 UCS_054 Wyświetlenie listy innych diagramów UML Przypadek umożliwia programiście przeglądanie listy diagramów UML innych niż diagram klas i diagram przypadków użycia (diagramów sekwencji, stanów, czynności itp.). USER_03_programista USER_03_UCS_052 UCS_057 Dodanie raportu z wdrożenia Przypadek umożliwia programiście umieszczenie w systemie sprawozdania z wdrożenia przeprowadzonego według specyfikacji wdrożenia pobranej za pomocą UCS_058. USER_03_programista USER_03_UCS_005 UCS_058 Przeglądanie specyfikacji wdrożenia Przypadek umożliwia programiście pobranie z systemu umieszczonej w nim przez kierownika projektu specyfikacji szczegółów wdrożenia, które programista winien przeprowadzić. USER_03_programista USER_03_UCS_005

70 Przypadki użycia dla USER_04_tester UCS_000 Wybór projektu Wybór projektu to współdzielony przypadek wszystkich aktorów w aplikacji poza USER_05. Pracownicy po stronie wykonawcy (USER 01 04) przed uzyskaniem dostępu do wyboru modułów, z których mogą korzystać wybierają aplikację, nad wytwarzaniem której aktualnie pracują. Przypadek użycia UCS_000 pozwala na dokonanie tego wyboru. USER_01 Kierownik projektu USER_01_UCS_009 UCS_00 Korzystanie z modułu kontroli testowania Wybór projektu to współdzielony przypadek wszystkich aktorów w aplikacji poza USER_05. Pracownicy po stronie wykonawcy (USER 01 04) przed uzyskaniem dostępu do wyboru modułów, z których mogą korzystać wybierają aplikację, nad wytwarzaniem której aktualnie pracują. Przypadek użycia UCS_000 pozwala na dokonanie tego wyboru. USER_01 Kierownik projektu USER_01_UCS_009 UCS_022 Wyświetlenie listy scenariuszy testowych Wybór projektu to współdzielony przypadek wszystkich aktorów w aplikacji poza USER_05. Pracownicy po stronie wykonawcy (USER 01 04) przed uzyskaniem dostępu do wyboru modułów, z których mogą korzystać wybierają aplikację, nad wytwarzaniem której aktualnie pracują. Przypadek użycia UCS_000 pozwala na dokonanie tego wyboru. USER_01 Kierownik projektu USER_01_UCS_009 UCS_055 Potwierdzenie poprawnej realizacji scenariusza przez aplikację Wybór projektu to współdzielony przypadek wszystkich aktorów w aplikacji poza USER_05. Pracownicy po stronie wykonawcy (USER 01 04) przed uzyskaniem dostępu do wyboru modułów, z których mogą korzystać wybierają aplikację, nad wytwarzaniem której aktualnie pracują. Przypadek użycia UCS_000 pozwala na dokonanie tego wyboru. USER_01 Kierownik projektu USER_01_UCS_009

71 Przypadki użycia dla USER_04_klient UCS_05 Przeglądanie wyników prac Przypadek użycia umożliwiający klientowi wgląd w moduł przeglądania wyników prac. USER_05_kKient USER_01_UCS_ Rozwinięcie przypadku użycia UCS_5 Obszarem o najwyższym ryzyku powstania niepożądanych zjawisk w procesie wytwarzania oprogramowania o ustalonym zakresie (ZP zakres projektu) jest obszar występowania sprzecznych interesów udziałowców projektu. Minimalizacja tego ryzyka w relacji klient specyfikacja wymagań (SW) wykonawca może odbyć się na drodze uznania specyfikacji podpisanej przed realizacją projektu za precyzyjny, niezmienny i jednoznaczny wyznacznik kształtu i zakresu projektu (ZP) tworzonego przez wykonawcę z uwzględnieniem określonego zwykle na wysokość nie wyższą niż 10% budżetu na zmiany (BNZ), z którego przypisywane są środki na modyfikacje, o które Klient wnioskuje w trakcie trwania projektu (ZD zakres dodatkowy). W przypadku projektów przekraczających 4 miesiące i więcej podpisany przed uruchomieniem prac kluczowy dokument SW może z dużym prawdopodobieństwem zostać przez Klienta zapomniany i zmiany wykraczające poza ZP + BNZ mogą stać się ze strony Klienta wymagalne dla zamknięcia projektu w zakresie podstawowym (ZP). Podczas trwania procesu wytwarzania oprogramowania Klient nabiera doświadczenia, kontaktuje się z osobami trzecimi oraz obserwuje materializujące się własne wyobrażenie na temat tego, czego potrzebuje i co opisał na wstępie. Powyższe czynniki wraz z kilkumiesięcznym okresem ich oddziaływania powodują, że konfrontacja Klienta z SW w końcowej chwili zamykania projektu protokołem odbioru może być dla niego nieakceptowalna i budująca przekonanie, iż specyfikacja, którą podpisał kilka miesięcy wcześniej, posiada cechy dokumentu wstępnego, utworzenie wielu rozszerzeń z zakresu dodatkowego ZD jest logiczne i wymagalne w sposób naturalny, co z punktu widzenia wykonawcy stanowi najbardziej niebezpieczną sytuację stanowiącą zagrożenie dla harmonogramów wewnętrznych mających bezpośrednie przełożenie na utrzymanie równowagi między obciążeniem zasobów i liczbą projektów zamkniętych z sukcesem. Opisana sytuacja obrazuje jeden z najtrudniejszych dylematów przedsiębiorcy odpowiedzialnego za realizację procesu wytwarzania oprogramowania. Istotą tego dylematu jest nieodłączny cel każdej firmy, jakim jest zapewnienie profesjonalizmu usług, skonfrontowany z możliwością nadużyć ze strony zamawiającej usługi. Liczne firmy, zwłaszcza z kategorii start-up IT posiadają ponadprzeciętną skłonność do nadgorliwego traktowania wymagań klienta, co z kolei skłania doświadczonych przedsiębiorców do nawiązywania współpracy z takimi firmami. Wsparcie zapobiegania sytuacji opisanej powyżej może odbyć się na drodze stałego informowania Klienta o postępach prac w poniższej formie:

72 Data ostatniej aktualizacji Dokument umowy wykonanie na Dokument specyfikacji wymagań (SW) Lista modułów, które zostały podpisane do realizacji w ramach SW Lista modułów zrealizowana do dnia: data_aktualna Data Wybrany sposób raportowania stawia jako główną przesłankę kontaktu informowanie klienta o postępach prac, co przemawia na korzyść wykonawcy, świadcząc o jego systematyczności. Podprogową informacją jest cykliczne uwidocznienie i przypominanie klientowi treści specyfikacji, która wiążę kontrahentów w ramach opracowywanego przyrostu. Przy zastosowanym podejściu łatwiej o zakwalifikowanie modyfikacji wnioskowanych przez Klienta w trakcie trwania procesu wytwarzania oprogramowania do zakresu rozszerzającego specyfikację początkową objętego osobnym, nowym budżetem, aniżeli funkcjonalność wynikająca z SW na trwający przyrost (ZP). Brak zgody na ponadnormatywne nadmuchiwanie wymagań paradoksalnie będzie przyczynkiem polepszenia wizerunku wykonawcy w oczach liczącego się na rynku podmiotu zamawiającego usługę.

73 Klasy systemu Poniższy diagram klas obejmuje tylko tzw. klasy biznesowe, a więc klasy istniejące w dziedzinie problemu. W czasie projektowania systemu PM model klas znajduje zastosowanie we wszystkich aspektach, a zwłaszcza w projekcie warstwy usług (warstwy biznesowej) i struktury danych Biznesowy diagram klas Rys. 25. Biznesowy diagram klas

74 Opis klas biznesowych CLS_001 Użytkownik Klasa reprezentuje użytkownika aplikacji Atrybuty: int id klucz główny tabeli varchar(50) imie atrybut typu varchar zawierający imię użytkownika Metody: varchar(50) nazwisko public Użytkownik() konstruktor klasy public int getid() public void setid(int val) public varchar(50): getimie() public void setimie(varchar(50): val) public varchar(50) getnazwisko() public void setnazwisko( varchar(50) val ) atrybut typu varchar zawierający nazwisko użytkownika CLS_002 Rola Klasa reprezentuje rolę systemową użytkownika systemu Atrybuty: int id klucz główny varchar(30) nazwa nazwa roli użytkownika Metody: public int getid() public void setid(int val) public varchar(30) getnazwa() public void setnazwa( varchar(30) val) public Rola() konstruktor klasy CLS_003 Użytkownik_ma_role Klasa asocjacyjna realizująca związek wiele do wiele występujący pomiędzy klasą Użytkownik a klasą Rola. Właściwości: int id_uzytkownik klucz główny użytkownika, który jest referowany do roli int id_rola int id klucz główny roli, która przypisywana jest do użytkownika klucz główny samej roli Metody: public int getid_uzytkownik() public void setid_uzytkownik(int val) public int getid_rola() public void setid_rola(int val) public int getid() public void setid(int val) CLS_004 użytkownik_pracuje_nad_aplikacją Klasa asocjacyjna realizująca związek wiele do wiele pomiędzy klasą Użytkownik a klasą Aplikacja_realizowana Właściwości: int id_uzytkownik klucz obcy użytkownika, który jest referowany do aplikacji, nad którą pracuje int id_aplikacja realizowana int id klucz obcy aplikacji, która przypisywana jest do użytkownika klucz główny klasy asocjacyjnej Metody: public int getid_uzytkownik() public void setid_uzytkownik(int val) public int getid_aplikacja_realizowana() public void setid_aplikacja_realizowana(int val)

75 public int getid() public void setid(int val) CLS_005 Aplikacja_realizowana Klasa reprezentuje aplikację / program / narzędzie będące przedmiotem procesu wytwarzania oprogramowania Atrybuty: int id klucz główny varchar(100) nazwa robocza nazwa robocza projektu Metody: date termin public Aplikacja_realizowana() konstruktor klasy public int getid() public void setid(int val) public varchar(100): getnazwa_robocza() public void setnazwa_robocza(varchar(100): val) public date gettermin() public void settermin(date val) data określająca deadline zakończenia procesu wytwarzania aplikacji CLS_00 Pakiet_realizowany Klasa będąca w relacji kompozycji z klasą CLS_005 (jeżeli zostanie skasowana instancja klasy Aplikacja_realizowana, obiekt klasy Pakiet_realizowany również zostanie skasowany). Atrybuty: int id klucz główny Metody: varchar(50) nazwa date termin public Pakiet_realizowany() konstruktor klasy public int getid() public void setid(int val) public varchar(50) getnazwa() public void setnazwa(varchar(50) val) public date gettermin() public void settermin( date val ) nazwa pakietu data określająca deadline zakończenia procesu wytwarzania pakietu CLS_007 Moduł_realizowany Klasa będąca w relacji kompozycji z klasą CLS_00 (jeżeli zostanie skasowana instancja klasy Pakiet_realizowany, obiekt klasy Moduł_realizowany również zostanie skasowany). Atrybuty: int id klucz główny Metody: varchar(50) nazwa date termin public Moduł_realizowany() konstruktor klasy public int getid() public void setid(int val) public varchar(50) getnazwa() public void setnazwa(varchar(50) val) public date gettermin() public void settermin(date val) nazwa modułu data określająca deadline zakończenia procesu wytwarzania modułu CLS_008 Moduł Klasa reprezentująca moduł aplikacji PM sterującej realizacją aplikacji będących przedmiotem procesu wytwarzania oprogramowania Atrybuty: int etap_cyklu_kaskadowego pole przyjmujące wartości integer, reprezentujące następujące znaczenie: 1 etap analiza

76 - 7-2 etap projektowania 3 etap implementacji 4 etap wdrożenia 5 etap testowania int id klucz główny tabeli Metody: public Moduł() konstruktor klasy public int getetap_cyklu_kaskadowego() public void setetap_cyklu_kaskadowego(int val) public int getid() public void setid( int val ) CLS_009 Dokument Klasa reprezentuje podstawową jednostkę organizacyjną informacji w aplikacji PM Atrybuty: varchar(50) typ pole określa typ dokumentu np. specyfikacja wymagań varchar(50) nazwa nazwa dokumentu nadana w systemie Metody: int id varchar(50) nazwa_na_dysku public Dokument( ) - konstruktor klasy public varchar(50) gettyp( ) public void settyp( varchar(50) val ) public varchar(50) getnazwa( ) public void setnazwa( varchar(50) val ) public int getid( ) public void setid( int val ) public varchar(50) getnazwa_na_dysku( ) public void setnazwa_na_dysku( varchar(50) val ) klucz główny pierwotna nazwa dokumentu CLS_010 Moduł_przechowuje_dokument Klasa asocjacyjna realizująca związek o krotności wiele do wiele Atrybuty: id_modul klucz obcy modułu, który jest referowany do dokumentu id_dokument int id Metody: public void setid_modul( int val ) public void setid_modul( int val ) public int getid_dokument( ) public void setid_dokument( int val ) klucz obcy dokumentu, który przypisany jest do danego modułu aplikacji PM klucz główny klasy asocjacyjnej

77 Estymacja wielkości bazy danych Tabela CLS_001 Wielkość po roku użytkowania 1MB CLS_002 1MB CLS_003 1MB CLS_004 1MB CLS_ MB CLS_00 100MB CLS_ MB CLS_ kB CLS_009 5GB CLS_010 1MB

78 Systemowy diagram klas Opis systemowego diagramu klas Rys.2. Systemowy diagram klas CLS_001 Atrybuty: Stage Klasa reprezentuje etap cyklu wytwórczego aplikacji id INT(11) unikalny identyfikator name VARCHAR(100) nazwa etapu stripped_name VARCHAR(100) nazwa skrócona, wykorzystywana do wyświetlania w pasku adresu do odbierania metodą GET created_at DATETIME data utworzenia rekordu updated_at DATETIME data ostatniej aktualizacji rekordu