Linia Lotnicza

Tomasz Dackiewicz

Piotr Komorek

Leszek Krupinski

Kierownik grupy projektowej

Sebastian Lusiński

Jacek Malinowski

Sebastian Wiśniewski

Copyright © 2004 Grupa Projektowa Linia Lotnicza

Spis treści

Rozdział 1. Dokument definicji wymagań	3

Cel projektu	3

Zakres projektu	3

Wymagania funkcjonalne	3

Wymagania niefunkcjonalne	4

Rozdział 2. Plan działań	5

Diagram Gantta	5

Kontrola postępów prac	5

Rozdział 3. Struktura organizacji zespołu projektowego	6

Struktura zespołu	6

Kompetencje	7

Rozdział 4. Standardy komunikacyjne	9

Standardy	9

Śledzenie błędów	9

Rozdział 5. Ankieta badania wymagań	10

Pracownik działu kadr	10

Pracownik działu logistyki	10

Pracownik placówki handlowej	11

Klient	11

Rozdział 6. Plan zapewnienia jakości	12

Zarządzanie	12

Dokumentacja	12

Standardy, praktyki konwencje i metryki	12

Standardy dokumentacyjne	12

Standardy kodowania	12

Standardy komentowania	12

Wybrane metryki ZJO	12

Ustalenia dotyczące sposobu monitorowania zgodności z planem	13

Przeglądy i audyty	13

Testowanie	13

Raportowanie problemów i akcje korygujące	13

Kontrola kodu	13

Kontrola mediów	13

Zbieranie, pielęgnacja i utrzymanie zapisów	13

Szkolenie	14

Zarządzanie ryzykiem	14

Przegląd pozostałej części projektu	14

Rozdział 7. Plan testowania oprogramowania	15

Klasyfikacja błędów	15

Lista testów	15

Harmonogram	17

Scenariusze akceptacji	17

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

Nie skorygowane punkty funkcyjne	18

Korekcja punktów funkcyjnych	18

Rezultat końcowy	19

Szacowanie koniecznych nakładów	19

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

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.

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.

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.

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

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ń.

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.

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).

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.

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.

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

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.

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.

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

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.

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.

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)

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.

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

pracownik działu logistyki

Przygotowywanie faktur

Ustalanie automatyki zamówień

Wprowadzanie danych o sprzęcie

pracownik placówki handlowej

Publikacja informacji na stronach internetowych

Dostęp do danych o lotach

klient

Rezerwacja biletów

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

Nie skorygowane punkty funkcyjne

Typ	Złożoność Niska Średnia Wysoka	Suma
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.

19

Leszek Krupiński

2004-01-20T00:53:17