Linia Lotnicza
 
Tomasz Dackiewicz
Piotr Komorek
Leszek Krupinski
Kierownik grupy projektowej
Sebastian Lusiñski
Jacek Malinowski
Sebastian Wi¶niewski

Linia Lotnicza
 Tomasz Dackiewicz
 Piotr Komorek
 Leszek Krupinski
 Sebastian Lusiñski
 Jacek Malinowski
 Sebastian Wi¶niewski
Copyright © 2004 Grupa Projektowa Linia Lotnicza

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

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
Przypisy
1. 	diagramy.mpp

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. (Nie jeste¶my w stanie przeprowadziæ testu dla maksymalnej ilo¶ci u¿ytkowników wymaganej przez zamawiaj±cego).
•	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. (Nie jeste¶my w stanie przeprowadziæ testu dla maksymalnej ilo¶ci u¿ytkowników wymaganej przez zamawiaj±cego).
•	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.