Linia Lotnicza

Tomasz Dackiewicz

Piotr Komorek

Leszek Krupinski

Kierownik grupy projektowej

Sebastian Lusiński

Jacek Malinowski

Sebastian Wiśniewski


Spis treści

1. Dokument definicji wymagań
Cel projektu
Zakres projektu
Wymagania funkcjonalne
Wymagania niefunkcjonalne
2. Plan działań
Diagram Gantta
Kontrola postępów prac
3. Struktura organizacji zespołu projektowego
Struktura zespołu
Kompetencje
4. Standardy komunikacyjne
Standardy
Śledzenie błędów
5. Ankieta badania wymagań
6. Plan zapewnienia jakości
Zarządzanie
Dokumentacja
Standardy, praktyki konwencje i metryki
Standardy dokumentacyjne
Standardy kodowania
Standardy komentowania
Wybrane metryki ZJO
Ustalenia dotyczące sposobu monitorowania zgodności z planem
Przeglądy i audyty
Testowanie
Raportowanie problemów i akcje korygujące
Kontrola kodu
Kontrola mediów
Zbieranie, pielęgnacja i utrzymanie zapisów
Szkolenie
Zarządzanie ryzykiem
Przegląd pozostałej części projektu
7. Plan testowania oprogramowania
Klasyfikacja błędów
Lista testów
Harmonogram
Scenariusze akceptacji
8. Oszacowanie złożoności oprogramowania
Nie skorygowane punkty funkcyjne
Korekcja punktów funkcyjnych
Rezultat końcowy
Szacowanie koniecznych nakładów

Rozdział 1. Dokument definicji wymagań

Cel projektu

Usprawnienie pracy linii lotniczych

Zakres projektu

  • Wspomaganie działu obsługi klienta

  • Obsługa sprzedaży i rezerwacji biletów

  • Prezentacja informacji

  • Pozyskiwanie informacji z bazy danych

  • Wspomaganie zarządzania lotami

  • Wymiana danych z innymi liniami lotniczymi

  • Wspomaganie obsługi naziemnej

  • Zarządzanie personelem

  • Obsługa testów kwalifikacyjnych

  • System do mierzenia wydajności pracy

  • Obsługa limitów bezpieczeństwa dla pracowników

Wymagania funkcjonalne

  • Przechowywanie informacji o lotach, personelu i sprzęcie

  • Publikowanie informacji o lotach, wolnych miejscach i cenach na terminalach lotniskowych i stronie internetowej

  • Automatyczne wysyłanie zamówień do firm cateringowych dostarczających posiłki

  • Rezerwacja biletów przez internet, telefonicznie lub osobiście w placówkach handlowych

  • Powiadamianie odpowiednich pracowników o konieczności odnowienia umów z lotniskami

  • Udostępnianie informacji placówkom handlowym

  • Wspomaganie procesu rekrutacji personelu poprzez rejestrowanie zgłoszeń oraz szacowanie dopasowania osoby do stanowiska na podstawie wyników testów kwalifikacyjnych

  • Przypisywanie pilotów do lotów na podstawie aktualnej lokalizacji z uwzględnieniem limitów bezpieczeństwa długości pracy pilota

  • Analiza ilości niezbędnego personelu w stosunku do ilości obsługiwanych lotów.

Wymagania niefunkcjonalne

  • W celu zmniejszenia kosztów, system powinien pracować pod kontrolą systemu Linux; mimo to, ze względu na wysoki stopień rozproszenia systemu, niezbędne jest zapewnienie wieloplatformowości

  • Baza danych powinna być archiwizowana raz dziennie

  • System powinien pracować w trybie replikacji, aby w wypadku awarii głównego systemu, system zapasowy automatycznie przejął kontrolę

  • Baza serwerowa systemu powinna mieć zapewnioną ciągłość zasilania poprzez zastosowanie systemu UPS z baterią zapewniającą przynajmniej 8 godzin pracy, oraz generatora z paliwem na kolejne 24 godziny

  • Dane przekazywane między serwerem systemu a aplikacjami klienckimi powinny być przekazywane kanałami szyfrowanymi

  • Aplikacja kliencka powinna być przygotowana w wersji graficznej oraz tekstowej

Rozdział 2. Plan działań

Diagram Gantta

Diagramy WBS i Gantta zostały przygotowane w postaci pliku programu Microsoft Project, załączonego do tego dokumentu (plik diagramy.mpp).

Kontrola postępów prac

Postęp prac będzie na bieżąco kontrolowany, w szczególności poprzez:

  • wykonywanie cyklicznych raportów na temat postępów prac, aktualnie wykonywanego zadania, stopnia jego realizacji

  • spotkania grup funkcyjnych

  • nadzór grupy kontroli jakości

Rozdział 3. Struktura organizacji zespołu projektowego

Struktura zespołu

Ze względu na rozmiar przedsięwzięcia, zespół będzie miał strukturę rozproszoną. Kontakt między grupami będzie się odbywał poprzez liderów grup funkcjonalnych.

Zespół projektowy będzie podzielony na osiem grup funkcjonalnych.

  • Grupa projektowania interfejsu

    • Opracowanie zasad projektowania interfejsu użytkownika

    • Projektowanie okien dialogowych

    • Projektowanie interfejsu WWW

  • Grupa implementacji

    • Przygotowanie środowiska programistycznego

    • Przygotowanie systemu współdzielenia kodu

    • Implementacja systemu

    • Kompilacja kodu

    • Wypełnianie bazy danych

    • Dokumentacja kodu

  • Grupa administracyjna

    • Przygotowywanie sprzętu i oprogramowania

    • Szkolenie klientów

    • Przydzielanie uprawnień do modyfikacji kodu

    • Wykonywanie kopii zapasowych

    • Utrzymywanie lokalnej kopii systemu

    • Zarządzanie lokalną bazą danych

    • Opieka nad bazą sprzętowo-programową zespołu

  • Grupa kontroli jakości

    • Kontrola wersji systemu przekazywanych klientowi

    • Zbieranie i przetwarzanie danych dotyczących jakości

    • Nadzór nad terminowością wykonywania zadań

    • Kontrola dokumentacji

    • Nadzór nad testami

    • Kontrolowanie przeprowadzania inspekcji i audytów

  • Grupa dokumentacji

    • Stworzenie dokumentacji technicznej, administracyjnej i użytkownika

  • Grupa konserwacji

    • Zbieranie raportów użytkowników systemu

    • Analiza działającego systemu

    • Przygotowywanie raportów dotyczących stanu instalacji

  • Grupa testowania

    • Przygotowanie planu testów

    • Przeprowadzanie testów

    • Przekazywanie raportów o błędach do odpowiednich zespołów

  • Grupa analizy

    • Kontakty z klientami

    • Przygotowanie wymagań

    • Kontrola kosztów

Kompetencje

  • Kierownik

    • Raporty

    • Planowanie

  • Analityk

    • Raporty

    • Planowanie

    • Analiza wymagań

    • Analiza postępu prac

    • Analiza jakości

  • Projektant

    • Raporty

    • Design

    • Wymagania sprzętowe

  • Konserwator projektu

    • Raporty

    • Analiza w czasie rzeczywistym

  • Programista

    • Implementacja

    • Testy kompatybilności

    • Testy i weryfikacja procedur

  • Tester

    • Raporty

    • Testowanie

    • Analiza wydajności

    • Testy i weryfikacja procedur

  • Administrator

    • Raporty

    • Wymagania sprzętowe

    • Konfiguracja sprzętowa

Rozdział 4. Standardy komunikacyjne

Standardy

W celu przyspieszenia komunikacji między członkami zespołu, cała komunikacja formalna odbywać się będzie w postaci elektronicznej. Stworzony zostanie system obiegu dokumentów, który będzie kontrolował położenie każdego dokumentu, poprawnie adresował ścieżkę (od nadawcy, przez kierowników odpowiednich grup, do odbiorcy). Będzie on także automatycznie archiwizował wszystkie dokumenty, a także przechowywał czas odebrania i nadania przez każdą osobę. Wszystkie dokumenty muszą być sygnowane kluczem PGP. Klucze te będą przechowywane na wydzielonym serwerze kluczy, poświadczone przez kierownika projektu.

Ze względu na obieg dokumentów poprzez aplikację kliencką, nie ma potrzeby definiowania określonych szablonów dokumentów.

Wszystkie dokumenty kierowane na zewnątrz zespołu projektowego muszą zostać zaakceptowane przez kierownika projektu. Dokumenty przekazywane na zewnątrz nie mogą być zapisane w formatach o zamkniętych specyfikacjach (włączając w to dokumenty w formacie Microsoft Word).

Do zdalnych, nieformalnych kontaktów uruchomiony zostanie wewnętrzny serwer usługi typu Instant Messanger.

Śledzenie błędów

Zgłaszanie błędów odbywać się będzie poprzez aplikację typu BTS (Bug Tracking System). Korzystanie z tej aplikacji odbywać się będzie przez przeglądarkę internetową. Każda osoba odpowiedzialna za testowanie (wliczając w to pracowników firmy wykonujących testy alfa) będzie zarejestrowana w systemie. Formularz zgłaszania błędu będzie zawierał pola dotyczące opisu błędu, warunków zajścia, powtarzalności, sugestii rozwiązania, wstępnej klasyfikacji błędu (według grup opisanych w dalszej części tego dokumentu). Taki "bilet" zgłoszeniowy jest następnie sprawdzany przez kierownika grupy testowania, przypisywany wstępnie stan (nierozwiązany, nie do rozwiązania, błąd, brak funkcjonalności itp), a także osoba odpowiedzialna za poprawienie danego błędu. Wszystkie informacje o zmianach stanu danego biletu są przekazywane do osoby zgłaszającej błąd, osoby poprawiającej błąd oraz do kierownika grupy testującej.

Rozdział 5. Ankieta badania wymagań

W systemie wyróżniono czterech aktorów: pracownika działu kadr, pracownika działu logistyki, pracownika placówki handlowej oraz klienta. Ze względu na różne potrzeby tych aktorów, przygotowano cztery ankiety, umożliwiające poznie wymagań tych aktorów.

Pracownik działu kadr

  1. Czy chciałbyś mieć możliwość przeprowadzania testów dla potencjalnych pracowników na komputerze?

    Test jest głównym sposobem oceny potencjalnego pracownika. Testy te mogą być przeprowadzane od razu na komputerze, z pominięciem "papierowej" metody.

  2. W jaki sposób chciałbyś dostawać informację o wyniku potencjalnego pracownika?

    Wyniki mogą być reprezentowane w postaci tak/nie, procentowej, punkowej, wykresu słabości i zalet.

  3. Czy chciałbyś mieć możliwość definiowania sposobu punktacji dla poszczególnych stanowisk pracy?

    W testach dla potencjalnych pracowników pewne pytania będą się powtarzać, lecz dla różnych stanowisk będą one miały różne znaczenie.

  4. Czy chciałbyś mieć możliwość drukowania testów oraz raportów z wyników?

    Niektóre firmy preferują przechowywanie dokumentów w wersji "tradycyjnej".

Pracownik działu logistyki

  1. Czy chciałbyś mieć możliwość ustalenia automatycznych zamówień?

    Automatyczne zamówienia wysyłane do dostawców mogą znacznie przyspieszyć pracę, lecz nie wszyscy mają zaufanie do takiego trybu przekazywania zamówień.

  2. Jakie informacje chciałbyś przechowywać w systemie?

    Baza danych to potężne narzędzie, lecz aby ją zaprojektować, trzeba wiedzieć jakie dane mają być w niej przechowywane.

  3. Czy potrzebny jest dostęp do danych handlowych poprzez urządzenia przenośne?

    Pracownik działu logistyki często pracuje "w terenie". Wtedy konieczne może być uzyskanie dostępu do danych przez urządzenie typu handheld (palmtop, telefon komórkowy).

  4. Czy chciałbyś mieć możliwość wydruku faktur?

    W chwili obecnej faktury co raz częściej przekazuje się drogą elektroniczną, lecz niekiedy firmy wymagają wersji papierowych.

  5. Czy chciałbyś mieć możliwość bezpośredniej wymiany danych między systemem a systemem dostawcy?

    Możliwa jest wymiana danych między różnymi systemami. Należy jednak ustalić, czy jest ona niezbędna, ponieważ zapewnienie takiej wymiany danych może być pracochłonne ze względu na różnice w formatach przechowywania danych.

  6. Czy chciałbyś mieć dostęp do danych przez przeglądarkę internetową?

    Specjalizowane aplikacje klienckie umożliwiają lepsze dostosowanie do systemu, lecz użytkownicy mogą preferować dostęp do danych przez przeglądarkę, gdyż znają to narzędzie i wiedzą jak się nim posługiwać.

Pracownik placówki handlowej

  1. Jaki system operacyjny jest używany w Twojej placówce?

    Przygotowanie listy używanych systemów operacyjnych jest niezbędne, gdyż należy to uwzględnić przy przygotowywaniu aplikacji klienckich.

  2. Wolisz dostęp do danych przez przeglądarkę internetową czy aplikację kliencką?

    Pracownicy często nie chcą korzystać z wyspecjalizowanych narzędzi, nie chcą się uczyć obsługi nowych programów.

  3. Do jakich danych potrzebujesz mieć dostęp?

    W celu lepszego zaprojektowania aplikacji klienckiej lub interfejsu przez przeglądarkę internetową niezbędne są informacje jakie dane muszą być prezentowane.

Klient

  1. Jaki sposób rezerwacji biletów jest dla Ciebie najwygodniejszy?

    Wygoda dostępu to kwestia subiektywna, lecz niektóre metody mogą być preferowane przez więcej osób niż inne.

  2. Czy zgodziłbyś się na trwałe przechowywanie Twoich danych osobowych w systemie?

    Obecnie wiele osób nie zgadza się na jakiekolwiek przechowywanie danych osobowych przez czas dłuższy niż do końca lotu.

  3. W jakim formacie chciałbyś otrzymywać formularze?

    Wiele firm, niesłusznie, wymusza na klientach używanie programu Microsoft Word. Jest wiele formatów, które mogą być odczytane przez darmowe programy (np. PDF czy format dokumentu Open Office)

  4. Jakie opcje chciałbyś móc podać przy rezerwacji biletu?

    Przykładowo: miejsce dla palących/niepalących, posiłek wegetariański, miejsce przy oknie.

Rozdział 6. Plan zapewnienia jakości

Zarządzanie

  • Organizacja

    Menadżer projektu wyznacza kierowników i przydziela im poszczególne zadania z których składa się cały projekt. Kierownicy są w pełni odpowiedzialni za powierzone im zadanie oraz sami określają ile osób jest im potrzebnych do realizacji konkretnego zadania. Osoby które są odpowiedzialne za testy zgłaszają problemy menadżerowi który przekazuje je do odpowiednich kierowników.

  • Zadania

    Zespół zarządzania jakością ma za zadanie kontrolować zgodność wykonanej pracy z przyjętymi standardami, jak wypadają testy wykonywane przez odpowiednie grupy osób, jak odbywa się komunikacja między zespołami oraz zaangażowanie personelu.

  • Odpowiedzialność

    Menadżer projektu jest odpowiedzialny za odpowiednie podzielenie projektu na konkretne zadanie, za które kierownicy są odpowiedzialni.

Dokumentacja

Każdy kierownik, gdy jego personel skończy prace nad zadaniem, musi stworzyć raport w którym zapisane będą wnioski, problemy napotkane podczas prowadzonych działań oraz udokumentowane wszelkie ustalenia. Następnie taki raport kierownik bezpośrednio przekazuje do menadżera. Menadżer grupuje raporty według zadań projektowych i nadaje im unikalne identyfikatory.

Standardy, praktyki konwencje i metryki

Standardy dokumentacyjne

Zostały przyjęte szablony dokumentów, według których pisana jest dokumentacja. Szablony określają co musi się znajdować na odpowiednim dokumencie oraz formatowanie tekstu (Rozdziały, numeracje, rozmiary czcionek).

Standardy kodowania

Określenie języków programowania, styl kodowania i nazewnictwo plików z kodem.

Standardy komentowania

Określenie odpowiednich komentarzy dla poszczególnych elementów. Każdy element musi mieć informacje w postaci komentarzy na temat jakiego rodzaju dane wejściowe przyjmuje, z jakich plików źródłowych korzysta oraz jakiego typu dane zwraca.

Wybrane metryki ZJO

  • Przenaszalność:

    stopień przenaszalności - określa jaki odsetek kodu jest napisany w językach działających na wielu platformach (np. JAVA, C++). Miarą stopnia przenaszalności jest "p" podawane w [%] i wyliczany jest jako stosunek ilości linii kodu użytecznego dla wielu platform do ilości linii kodu całego programu.

  • Skalowalność:

    stopień skalowalności - określa rozmiar bazy danych, który program jest stanie obsłużyć. Miarą stopnia skalowalności jest "s" podawane w [MB], wyliczone na podstawie testów po wprowadzeniu pewnych danych do bazy aż do krytycznego spowolnienia pracy systemu.

Ustalenia dotyczące sposobu monitorowania zgodności z planem

Monitorowanie zgodności z planem jest przeprowadzane przez zespół zapewnienia jakości podczas kontroli wykonanych prac, planu przydziału zadań stworzonego przez menadżera projektu oraz kontroli grup projektowych.

Przeglądy i audyty

Będą przeprowadzane inspekcje wewnętrzne przeprowadzane przez grupę zapewnienia jakości oprogramowania. Zespoły projektowe będą miały dostęp do niezależnej grupy ekspertów, którą wyznacza menadżer projektu. Audyty będą odbywały się po zakończeniu każdej fazy projektu.

Testowanie

Testy będą przeprowadzane przez trzy niezależne grupy testujące aby zapewnić większy obiektywizm przeprowadzanych testów a ich wyniki będą weryfikowane do czasu uzyskania zbliżonych wartości.

Raportowanie problemów i akcje korygujące

Wszystkie problemy zgłaszane są menadżerowi, który zleca poprawienie błędu kierownikowi odpowiedzialnemu za daną część projektu, w której problem wynikł. Akcja jest powtarzana do całkowitego wyeliminowania problemu.

Kontrola kodu

Każdy fragment oprogramowania jest przechowywany na serwerze projektowym który codziennie tworzy kopie zapasowe. Personel ma obowiązek przesyłać co najemnej raz dziennie, na ten serwer, aktualny stan swojej pracy.

Kontrola mediów

Kopie zapasowe serwera które są wykonywane codziennie tworzone są na 7 kasetach DAT oznaczonych każdym dniem tygo dnia, a kopie wykonywane co tydzień na płytach CDR.

Zbieranie, pielęgnacja i utrzymanie zapisów

Sekretarz jest odpowiedzialny za prowadzenie kronik spotkań oraz wprowadzaniem ich do bazy danych na serwerze projektowym. Kroniki zawierają raporty ze wszystkich spotkań zespołu projektowego, notatki, korespondencje z grupą zamawiającą projekt.

Szkolenie

Szkolenia będą prowadzone przez osoby które brały udział w tworzeniu tego projektu i będą wyznaczane przez kierowników poszczególnych grup a o ich ostatecznym przydzieleniu do grupy szkoleniowej będzie decydował menadżer.

Zarządzanie ryzykiem

Na początku każdej fazy przeprowadzana jest ogólna analiza ryzyka. Polega ona na wyszczególnieniu najbardziej ryzykownych elementów projektu. Menadżer projektu ma za zadanie sprawdzać wymagania użytkownika, plany, procedury i dokumenty na zgodność ze standardami i przyjętymi procedurami postępowania.

Przegląd pozostałej części projektu

Po każdej inspekcji przeprowadzana jest analiza projektu pod kątem kosztów, zużytego czasu realizacji, prognozy co do terminu zakończenia projektu oraz sensowności dalszego prowadzenia projektu.

Rozdział 7. Plan testowania oprogramowania

Klasyfikacja błędów

  • Funkcjonalne

    Funkcja źle wykonana bądź źle funkcjonująca

  • Systemowe

    nieprawidłowe zarządzanie zasobami, mylne interfejsy, zła komunikacja z bazą danych bądź jej brak

  • Przetwarzania

    niewłaściwe przetwarzanie danych w poszczególnych modułach

  • Danych

    źle wprowadzone dane, ich brak, błędna specyfikacja

  • Graficzne

    interfejs graficzny niezgodny z założeniami

  • Kodowania

    niewłaściwe użycie języka programowania

  • Dokumentacji

    niepełna lub błędna dokumentacja

  • Inne

    niezidentyfikowana przyczyna wystąpienia

Lista testów

  • Analiza kodu

  • Testy funkcjonalne poszczególnych modułów systemu

    Przetestowana szczegółowo zostanie każda funkcja systemu wynikająca z dokumentacji. Ocenione zostaną: obecność (lub nieobecność funkcji), poprawność jej działania oraz szybkość działania. W przypadku braku funkcji lub nieprawidłowego działania należy wprowadzić poprawki. Jeśli funkcja działa zbyt wolno (oczekiwany i maksymalny czas reakcji - patrz dokumentacja odpowiednich funkcji) zalecana jest optymalizacja.

  • Test porównawczy wyników otrzymanych z oczekiwanymi

    Ze względu na konieczność współpracy ze sobą wszystkich modułów systemu przyjmujemy model testowania zstępującego.

  • Testy obciążenia

    Wykonany na maszynie z minimalną konfiguracją sprzętową, oraz konfiguracjami bardziej rozbudowanymi. Na podstawie otrzymanych wyników przeprowadzamy ocenę przypuszczalnej wydajności systemu na platformie docelowej.

  • Testy odpornościowe

    Podczas testów zostanie wywołana seria sytuacji awaryjnych (wyłączenia prądu, restarty systemu, znanaczne zwiększenie obciążenia serwera), zarówno w czasie "typowego" jak i "nietypowego" działania systemu. Po przywróceniu normalnej pracy systemu zostanie w każdym przypadku przeprowadzona szczegółowa analiza skutków sytuacji.

  • Test zużycia zasobów przez system

    Przeprowadzone równolegle z testem wydajności systemu za pomocą firmowego oprogramowania monitorującego. Na podstawie otrzymanych wyników przeprowadzamy ocenę przypuszczalnego zużycia zasobów na platformie docelowej.

  • Testy wydajności

  • Testy niezawodności

    Niezawodność oceniona zostanie na podstawie wyników ankiet wypełnianych przez testujących w pozostałych testach, jak również analizy dzienników tworzonych automatycznie przez system podczas tych testów. Ponadto przez pierwsze 3 miesiące po wdrożeniu systemu przedstawiciele firmy będą prowadzili dalsze analizy niezawodności (równolegle z analizą pozostałych parametrów pracy systemu).

  • Test bezpieczeństwa

    Kontrola dwuetapowa. W pierwszym etapie próbę złamania zabezpieczeń systemu przeprowadzi zespół firmowy, w drugim wynajęta specjalistyczna firma.

  • Test ergonomii interfejsu

    Ocena zgodności wykonanego interfejsu z projektami zatwierdzonymi przez użytkownika przez dwa zespoły - firmowy oraz niezależny. Pożądany udział przedstawicieli zamawiającego w jednym (lub obu) zespołach. Poza zgodnością wykonania zespół firmowy oceni również spójność interfejsu.

  • Testy funkcjonalne uruchamiania i działania procesów

  • Testy modyfikowalności oprogramowania

    Dwa firmowe zespoły programistów nie związane z implementacją tego systemu otrzymają polecenie wprowadzenia poprawek do działania kilku z funkcji systemu oraz uzupełnienia systemu o dodatkowe funkcje. W wypadku braku wolnych zespołów w tym czasie możliwe jest zlecenie tego wykonawcy zewnęt rznemu (choć nie jest to zalecane ze względu na wyższe koszty). Po zakończeniu modyfikacji zespoły te wypełnią ankiety służące do oceny łatwości wprowadzenia zmian, działanie zaś samych modyfikacji, jak również reszty systemu zostanie ponownie przetestowane (tylko na poprawność działania). Przypuszczalnie zostaną przeprowadzone dodatkowe "testy" ze względu na zmianę wymagań przez użytkownika w trakcie realizacji systemu.

  • Testy skalowalności systemu

    Przeprowadzana razem z testem zużycia zasobów, na podstawie tych samych danych, uzupełnionych o czas reakcji systemu oceniany przez użytkownika. Dane uzyskane podczas testu zostaną przeanalizowane pod katem pracy systemu przy dużych obciążeniach.

  • Testy alfa

    Przeprowadzona w formie odbioru systemu przez przedstawicieli użytkownika. Przedstawiciele dostają wolną rękę w testowaniu systemu, pełną pomoc personelu firmy. Wynikiem testu będzie ocena systemu wystawiona przez przedstawicieli użytkownika.

  • Przegląd jakości dokumentacji

    Test zostanie przeprowadzony w formie szkolenia przyszłych użytkowników systemu. Po zakończeniu szkolenia wypełnią oni ankietę przeznaczoną do oceny jakości materiałów dydaktycznych. Następnie zostanie przeprowadzona symulacja rzeczywistych działań przy użyciu systemu. Zespół firmowy (ew. uzupełniony o przedstawicieli klienta - b. pożądane) oceni jakość działań pracowników, a co za tym idzie ich stopień przygotowania do pracy. Na podstawie tych danych zostanie oceniona dokumentacja systemu oraz sam proces szkolenia.

Harmonogram

  • Testy modułów

    Testy te zostaną przeprowadzone w fazie implementacji, po zakończeniu realizacji poszczególnych modułów.

  • Testy systemu

    Testy przeprowadzane po integracji modułów. System jest już testowany jako spójna całość.

  • Testy akceptacji (testy alfa)

    Test przeprowadzany przez końcowych użytkowników systemu.

Scenariusze akceptacji

Ze względu na specyfikę testów, przygotowanie poszczególnych testów funkcjonalności zostało podzielone według aktorów występujących w systemie.

  1. pracownik działu kadr

    • Przygotywywanie testów

    • Ustalanie parametrów testów

    • Przeprowadzanie testów

    • Przygotowywanie raportów

    • Generowanie analiz potrzeb personalnych

    • Przypisywanie pilotów do lotów

  2. pracownik działu logistyki

    • Przygotowywanie faktur

    • Ustalanie automatyki zamówień

    • Wprowadzanie danych o sprzęcie

  3. pracownik placówki handlowej

    • Publikacja informacji na stronach internetowych

    • Dostęp do danych o lotach

  4. klient

    • Rezerwacja biletów

Rozdział 8. Oszacowanie złożoności oprogramowania

Nie skorygowane punkty funkcyjne

Typ Złożoność Suma
  Niska Średnia Wysoka  
Wejścia użytkownika 19 * 4 15 * 5 13 * 6 229
Wyjścia użytkownika 19 * 5 15 * 6 13 * 7 276
Zbiory danych wewnętrzne 20 * 5 15 * 10 20 * 15 550
Zbiory danych zewnętrzne 5 * 5 2 * 7 2 * 9 57
Zapytania zewnętrzne 9 * 4 5 * 6 2 * 8 82
Suma nie skorygowanych (UFP) 1194

Korekcja punktów funkcyjnych

Nr Ogólna charakterystyka sytemu Punkt
1. Występowanie urządzeń komunikacyjnych 3
2. Rozproszenie przetwarzania 1
3. Wymagane parametry szybkości działania 2
4. Skomplikowana logika przetwarzania 1
5. Obciążenie systemu - liczba transakcji 4
6. Wprowadzanie danych w trybie online 4
7. Wydajność użytkownika końcowego 2
8. Aktualizacja danych w trybie online 3
9. Rozproszenie terytorialne 4
10. Złożoność przetwarzania danych 2
11. Przenośność 5
12. Prostota instalacji 1
13. Prostota obsługi 3
14. Zmiany w okresie eksploatacji 1
  Suma (VAF) 36

Rezultat końcowy

VAF = 36

FP = (0.65 + 0.01*VAF) * UFP

FP = 1.01 * 1194 = 1205.94

Szacowanie koniecznych nakładów

1205.94 punktów funkcyjnych odpowiada pracochłonności około 120 osobomiesiącom.