Linia Lotnicza


Spis tresci

1. Dokument definicji wymagan
Cel projektu
Zakres projektu
Wymagania funkcjonalne
Wymagania niefunkcjonalne
2. Plan dzialan
Diagram Gantta
Kontrola postepow prac
3. Struktura organizacji zespolu projektowego
Struktura zespolu
Kompetencje
4. Standardy komunikacyjne
Standardy
Sledzenie bledow
5. Ankieta badania wymagan
6. Plan zapewnienia jakosci
Zarzadzanie
Dokumentacja
Standardy, praktyki konwencje i metryki
Standardy dokumentacyjne
Standardy kodowania
Standardy komentowania
Wybrane metryki ZJO
Ustalenia dotyczace sposobu monitorowania zgodnosci z planem
Przeglady i audyty
Testowanie
Raportowanie problemow i akcje korygujace
Kontrola kodu
Kontrola mediow
Zbieranie, pielegnacja i utrzymanie zapisow
Szkolenie
Zarzadzanie ryzykiem
Przeglad pozostalej czesci projektu
7. Plan testowania oprogramowania
Klasyfikacja bledow
Lista testow
Harmonogram
Scenariusze akceptacji
8. Oszacowanie zlozonosci oprogramowania
Nie skorygowane punkty funkcyjne
Korekcja punktow funkcyjnych
Rezultat koncowy
Szacowanie koniecznych nakladow

Rozdzial 1. Dokument definicji wymagan

Cel projektu

Usprawnienie pracy linii lotniczych

Zakres projektu

  • Wspomaganie dzialu obslugi klienta

  • Obsluga sprzedazy i rezerwacji biletow

  • Prezentacja informacji

  • Pozyskiwanie informacji z bazy danych

  • Wspomaganie zarzadzania lotami

  • Wymiana danych z innymi liniami lotniczymi

  • Wspomaganie obslugi naziemnej

  • Zarzadzanie personelem

  • Obsluga testow kwalifikacyjnych

  • System do mierzenia wydajnosci pracy

  • Obsluga limitow bezpieczenstwa dla pracownikow

Wymagania funkcjonalne

  • Przechowywanie informacji o lotach, personelu i sprzecie

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

  • Automatyczne wysylanie zamowien do firm cateringowych dostarczajacych posilki

  • Rezerwacja biletow przez internet, telefonicznie lub osobiscie w placowkach handlowych

  • Powiadamianie odpowiednich pracownikow o koniecznosci odnowienia umow z lotniskami

  • Udostepnianie informacji placowkom handlowym

  • Wspomaganie procesu rekrutacji personelu poprzez rejestrowanie zgloszen oraz szacowanie dopasowania osoby do stanowiska na podstawie wynikow testow kwalifikacyjnych

  • Przypisywanie pilotow do lotow na podstawie aktualnej lokalizacji z uwzglednieniem limitow bezpieczenstwa dlugosci pracy pilota

  • Analiza ilosci niezbednego personelu w stosunku do ilosci obslugiwanych lotow.

Wymagania niefunkcjonalne

  • W celu zmniejszenia kosztow, system powinien pracowac pod kontrola systemu Linux; mimo to, ze wzgledu na wysoki stopien rozproszenia systemu, niezbedne jest zapewnienie wieloplatformowosci

  • Baza danych powinna byc archiwizowana raz dziennie

  • System powinien pracowac w trybie replikacji, aby w wypadku awarii glownego systemu, system zapasowy automatycznie przejal kontrole

  • Baza serwerowa systemu powinna miec zapewniona ciaglosc zasilania poprzez zastosowanie systemu UPS z bateria zapewniajaca przynajmniej 8 godzin pracy, oraz generatora z paliwem na kolejne 24 godziny

  • Dane przekazywane miedzy serwerem systemu a aplikacjami klienckimi powinny byc przekazywane kanalami szyfrowanymi

  • Aplikacja kliencka powinna byc przygotowana w wersji graficznej oraz tekstowej

Rozdzial 2. Plan dzialan

Diagram Gantta

Diagramy WBS i Gantta zostaly przygotowane w postaci pliku programu Microsoft Project, zalaczonego do tego dokumentu (plik diagramy.mpp).

Kontrola postepow prac

Postep prac bedzie na biezaco kontrolowany, w szczegolnosci poprzez:

  • wykonywanie cyklicznych raportow na temat postepow prac, aktualnie wykonywanego zadania, stopnia jego realizacji

  • spotkania grup funkcyjnych

  • nadzor grupy kontroli jakosci

Rozdzial 3. Struktura organizacji zespolu projektowego

Struktura zespolu

Ze wzgledu na rozmiar przedsiewziecia, zespol bedzie mial strukture rozproszona. Kontakt miedzy grupami bedzie sie odbywal poprzez liderow grup funkcjonalnych.

Zespol projektowy bedzie podzielony na osiem grup funkcjonalnych.

  • Grupa projektowania interfejsu

    • Opracowanie zasad projektowania interfejsu uzytkownika

    • Projektowanie okien dialogowych

    • Projektowanie interfejsu WWW

  • Grupa implementacji

    • Przygotowanie srodowiska programistycznego

    • Przygotowanie systemu wspoldzielenia kodu

    • Implementacja systemu

    • Kompilacja kodu

    • Wypelnianie bazy danych

    • Dokumentacja kodu

  • Grupa administracyjna

    • Przygotowywanie sprzetu i oprogramowania

    • Szkolenie klientow

    • Przydzielanie uprawnien do modyfikacji kodu

    • Wykonywanie kopii zapasowych

    • Utrzymywanie lokalnej kopii systemu

    • Zarzadzanie lokalna baza danych

    • Opieka nad baza sprzetowo-programowa zespolu

  • Grupa kontroli jakosci

    • Kontrola wersji systemu przekazywanych klientowi

    • Zbieranie i przetwarzanie danych dotyczacych jakosci

    • Nadzor nad terminowoscia wykonywania zadan

    • Kontrola dokumentacji

    • Nadzor nad testami

    • Kontrolowanie przeprowadzania inspekcji i audytow

  • Grupa dokumentacji

    • Stworzenie dokumentacji technicznej, administracyjnej i uzytkownika

  • Grupa konserwacji

    • Zbieranie raportow uzytkownikow systemu

    • Analiza dzialajacego systemu

    • Przygotowywanie raportow dotyczacych stanu instalacji

  • Grupa testowania

    • Przygotowanie planu testow

    • Przeprowadzanie testow

    • Przekazywanie raportow o bledach do odpowiednich zespolow

  • Grupa analizy

    • Kontakty z klientami

    • Przygotowanie wymagan

    • Kontrola kosztow

Kompetencje

  • Kierownik

    • Raporty

    • Planowanie

  • Analityk

    • Raporty

    • Planowanie

    • Analiza wymagan

    • Analiza postepu prac

    • Analiza jakosci

  • Projektant

    • Raporty

    • Design

    • Wymagania sprzetowe

  • Konserwator projektu

    • Raporty

    • Analiza w czasie rzeczywistym

  • Programista

    • Implementacja

    • Testy kompatybilnosci

    • Testy i weryfikacja procedur

  • Tester

    • Raporty

    • Testowanie

    • Analiza wydajnosci

    • Testy i weryfikacja procedur

  • Administrator

    • Raporty

    • Wymagania sprzetowe

    • Konfiguracja sprzetowa

Rozdzial 4. Standardy komunikacyjne

Standardy

W celu przyspieszenia komunikacji miedzy czlonkami zespolu, cala komunikacja formalna odbywac sie bedzie w postaci elektronicznej. Stworzony zostanie system obiegu dokumentow, ktory bedzie kontrolowal polozenie kazdego dokumentu, poprawnie adresowal sciezke (od nadawcy, przez kierownikow odpowiednich grup, do odbiorcy). Bedzie on takze automatycznie archiwizowal wszystkie dokumenty, a takze przechowywal czas odebrania i nadania przez kazda osobe. Wszystkie dokumenty musza byc sygnowane kluczem PGP. Klucze te beda przechowywane na wydzielonym serwerze kluczy, poswiadczone przez kierownika projektu.

Ze wzgledu na obieg dokumentow poprzez aplikacje kliencka, nie ma potrzeby definiowania okreslonych szablonow dokumentow.

Wszystkie dokumenty kierowane na zewnatrz zespolu projektowego musza zostac zaakceptowane przez kierownika projektu. Dokumenty przekazywane na zewnatrz nie moga byc zapisane w formatach o zamknietych specyfikacjach (wlaczajac w to dokumenty w formacie Microsoft Word).

Do zdalnych, nieformalnych kontaktow uruchomiony zostanie wewnetrzny serwer uslugi typu Instant Messanger.

Sledzenie bledow

Zglaszanie bledow odbywac sie bedzie poprzez aplikacje typu BTS (Bug Tracking System). Korzystanie z tej aplikacji odbywac sie bedzie przez przegladarke internetowa. Kazda osoba odpowiedzialna za testowanie (wliczajac w to pracownikow firmy wykonujacych testy alfa) bedzie zarejestrowana w systemie. Formularz zglaszania bledu bedzie zawieral pola dotyczace opisu bledu, warunkow zajscia, powtarzalnosci, sugestii rozwiazania, wstepnej klasyfikacji bledu (wedlug grup opisanych w dalszej czesci tego dokumentu). Taki "bilet" zgloszeniowy jest nastepnie sprawdzany przez kierownika grupy testowania, przypisywany wstepnie stan (nierozwiazany, nie do rozwiazania, blad, brak funkcjonalnosci itp), a takze osoba odpowiedzialna za poprawienie danego bledu. Wszystkie informacje o zmianach stanu danego biletu sa przekazywane do osoby zglaszajacej blad, osoby poprawiajacej blad oraz do kierownika grupy testujacej.

Rozdzial 5. Ankieta badania wymagan

W systemie wyrozniono czterech aktorow: pracownika dzialu kadr, pracownika dzialu logistyki, pracownika placowki handlowej oraz klienta. Ze wzgledu na rozne potrzeby tych aktorow, przygotowano cztery ankiety, umozliwiajace poznie wymagan tych aktorow.

Pracownik dzialu kadr

  1. Czy chcialbys miec mozliwosc przeprowadzania testow dla potencjalnych pracownikow na komputerze?

    Test jest glownym sposobem oceny potencjalnego pracownika. Testy te moga byc przeprowadzane od razu na komputerze, z pominieciem "papierowej" metody.

  2. W jaki sposob chcialbys dostawac informacje o wyniku potencjalnego pracownika?

    Wyniki moga byc reprezentowane w postaci tak/nie, procentowej, punkowej, wykresu slabosci i zalet.

  3. Czy chcialbys miec mozliwosc definiowania sposobu punktacji dla poszczegolnych stanowisk pracy?

    W testach dla potencjalnych pracownikow pewne pytania beda sie powtarzac, lecz dla roznych stanowisk beda one mialy rozne znaczenie.

  4. Czy chcialbys miec mozliwosc drukowania testow oraz raportow z wynikow?

    Niektore firmy preferuja przechowywanie dokumentow w wersji "tradycyjnej".

Pracownik dzialu logistyki

  1. Czy chcialbys miec mozliwosc ustalenia automatycznych zamowien?

    Automatyczne zamowienia wysylane do dostawcow moga znacznie przyspieszyc prace, lecz nie wszyscy maja zaufanie do takiego trybu przekazywania zamowien.

  2. Jakie informacje chcialbys przechowywac w systemie?

    Baza danych to potezne narzedzie, lecz aby ja zaprojektowac, trzeba wiedziec jakie dane maja byc w niej przechowywane.

  3. Czy potrzebny jest dostep do danych handlowych poprzez urzadzenia przenosne?

    Pracownik dzialu logistyki czesto pracuje "w terenie". Wtedy konieczne moze byc uzyskanie dostepu do danych przez urzadzenie typu handheld (palmtop, telefon komorkowy).

  4. Czy chcialbys miec mozliwosc wydruku faktur?

    W chwili obecnej faktury co raz czesciej przekazuje sie droga elektroniczna, lecz niekiedy firmy wymagaja wersji papierowych.

  5. Czy chcialbys miec mozliwosc bezposredniej wymiany danych miedzy systemem a systemem dostawcy?

    Mozliwa jest wymiana danych miedzy roznymi systemami. Nalezy jednak ustalic, czy jest ona niezbedna, poniewaz zapewnienie takiej wymiany danych moze byc pracochlonne ze wzgledu na roznice w formatach przechowywania danych.

  6. Czy chcialbys miec dostep do danych przez przegladarke internetowa?

    Specjalizowane aplikacje klienckie umozliwiaja lepsze dostosowanie do systemu, lecz uzytkownicy moga preferowac dostep do danych przez przegladarke, gdyz znaja to narzedzie i wiedza jak sie nim poslugiwac.

Pracownik placowki handlowej

  1. Jaki system operacyjny jest uzywany w Twojej placowce?

    Przygotowanie listy uzywanych systemow operacyjnych jest niezbedne, gdyz nalezy to uwzglednic przy przygotowywaniu aplikacji klienckich.

  2. Wolisz dostep do danych przez przegladarke internetowa czy aplikacje kliencka?

    Pracownicy czesto nie chca korzystac z wyspecjalizowanych narzedzi, nie chca sie uczyc obslugi nowych programow.

  3. Do jakich danych potrzebujesz miec dostep?

    W celu lepszego zaprojektowania aplikacji klienckiej lub interfejsu przez przegladarke internetowa niezbedne sa informacje jakie dane musza byc prezentowane.

Klient

  1. Jaki sposob rezerwacji biletow jest dla Ciebie najwygodniejszy?

    Wygoda dostepu to kwestia subiektywna, lecz niektore metody moga byc preferowane przez wiecej osob niz inne.

  2. Czy zgodzilbys sie na trwale przechowywanie Twoich danych osobowych w systemie?

    Obecnie wiele osob nie zgadza sie na jakiekolwiek przechowywanie danych osobowych przez czas dluzszy niz do konca lotu.

  3. W jakim formacie chcialbys otrzymywac formularze?

    Wiele firm, nieslusznie, wymusza na klientach uzywanie programu Microsoft Word. Jest wiele formatow, ktore moga byc odczytane przez darmowe programy (np. PDF czy format dokumentu Open Office)

  4. Jakie opcje chcialbys moc podac przy rezerwacji biletu?

    Przykladowo: miejsce dla palacych/niepalacych, posilek wegetarianski, miejsce przy oknie.

Rozdzial 6. Plan zapewnienia jakosci

Zarzadzanie

  • Organizacja

    Menadzer projektu wyznacza kierownikow i przydziela im poszczegolne zadania z ktorych sklada sie caly projekt. Kierownicy sa w pelni odpowiedzialni za powierzone im zadanie oraz sami okreslaja ile osob jest im potrzebnych do realizacji konkretnego zadania. Osoby ktore sa odpowiedzialne za testy zglaszaja problemy menadzerowi ktory przekazuje je do odpowiednich kierownikow.

  • Zadania

    Zespol zarzadzania jakoscia ma za zadanie kontrolowac zgodnosc wykonanej pracy z przyjetymi standardami, jak wypadaja testy wykonywane przez odpowiednie grupy osob, jak odbywa sie komunikacja miedzy zespolami oraz zaangazowanie personelu.

  • Odpowiedzialnosc

    Menadzer projektu jest odpowiedzialny za odpowiednie podzielenie projektu na konkretne zadanie, za ktore kierownicy sa odpowiedzialni.

Dokumentacja

Kazdy kierownik, gdy jego personel skonczy prace nad zadaniem, musi stworzyc raport w ktorym zapisane beda wnioski, problemy napotkane podczas prowadzonych dzialan oraz udokumentowane wszelkie ustalenia. Nastepnie taki raport kierownik bezposrednio przekazuje do menadzera. Menadzer grupuje raporty wedlug zadan projektowych i nadaje im unikalne identyfikatory.

Standardy, praktyki konwencje i metryki

Standardy dokumentacyjne

Zostaly przyjete szablony dokumentow, wedlug ktorych pisana jest dokumentacja. Szablony okreslaja co musi sie znajdowac na odpowiednim dokumencie oraz formatowanie tekstu (Rozdzialy, numeracje, rozmiary czcionek).

Standardy kodowania

Okreslenie jezykow programowania, styl kodowania i nazewnictwo plikow z kodem.

Standardy komentowania

Okreslenie odpowiednich komentarzy dla poszczegolnych elementow. Kazdy element musi miec informacje w postaci komentarzy na temat jakiego rodzaju dane wejsciowe przyjmuje, z jakich plikow zrodlowych korzysta oraz jakiego typu dane zwraca.

Wybrane metryki ZJO

  • Przenaszalnosc:

    stopien przenaszalnosci - okresla jaki odsetek kodu jest napisany w jezykach dzialajacych na wielu platformach (np. JAVA, C++). Miara stopnia przenaszalnosci jest "p" podawane w [%] i wyliczany jest jako stosunek ilosci linii kodu uzytecznego dla wielu platform do ilosci linii kodu calego programu.

  • Skalowalnosc:

    stopien skalowalnosci - okresla rozmiar bazy danych, ktory program jest stanie obsluzyc. Miara stopnia skalowalnosci jest "s" podawane w [MB], wyliczone na podstawie testow po wprowadzeniu pewnych danych do bazy az do krytycznego spowolnienia pracy systemu.

Ustalenia dotyczace sposobu monitorowania zgodnosci z planem

Monitorowanie zgodnosci z planem jest przeprowadzane przez zespol zapewnienia jakosci podczas kontroli wykonanych prac, planu przydzialu zadan stworzonego przez menadzera projektu oraz kontroli grup projektowych.

Przeglady i audyty

Beda przeprowadzane inspekcje wewnetrzne przeprowadzane przez grupe zapewnienia jakosci oprogramowania. Zespoly projektowe beda mialy dostep do niezaleznej grupy ekspertow, ktora wyznacza menadzer projektu. Audyty beda odbywaly sie po zakonczeniu kazdej fazy projektu.

Testowanie

Testy beda przeprowadzane przez trzy niezalezne grupy testujace aby zapewnic wiekszy obiektywizm przeprowadzanych testow a ich wyniki beda weryfikowane do czasu uzyskania zblizonych wartosci.

Raportowanie problemow i akcje korygujace

Wszystkie problemy zglaszane sa menadzerowi, ktory zleca poprawienie bledu kierownikowi odpowiedzialnemu za dana czesc projektu, w ktorej problem wynikl. Akcja jest powtarzana do calkowitego wyeliminowania problemu.

Kontrola kodu

Kazdy fragment oprogramowania jest przechowywany na serwerze projektowym ktory codziennie tworzy kopie zapasowe. Personel ma obowiazek przesylac co najemnej raz dziennie, na ten serwer, aktualny stan swojej pracy.

Kontrola mediow

Kopie zapasowe serwera ktore sa wykonywane codziennie tworzone sa na 7 kasetach DAT oznaczonych kazdym dniem tygo dnia, a kopie wykonywane co tydzien na plytach CDR.

Zbieranie, pielegnacja i utrzymanie zapisow

Sekretarz jest odpowiedzialny za prowadzenie kronik spotkan oraz wprowadzaniem ich do bazy danych na serwerze projektowym. Kroniki zawieraja raporty ze wszystkich spotkan zespolu projektowego, notatki, korespondencje z grupa zamawiajaca projekt.

Szkolenie

Szkolenia beda prowadzone przez osoby ktore braly udzial w tworzeniu tego projektu i beda wyznaczane przez kierownikow poszczegolnych grup a o ich ostatecznym przydzieleniu do grupy szkoleniowej bedzie decydowal menadzer.

Zarzadzanie ryzykiem

Na poczatku kazdej fazy przeprowadzana jest ogolna analiza ryzyka. Polega ona na wyszczegolnieniu najbardziej ryzykownych elementow projektu. Menadzer projektu ma za zadanie sprawdzac wymagania uzytkownika, plany, procedury i dokumenty na zgodnosc ze standardami i przyjetymi procedurami postepowania.

Przeglad pozostalej czesci projektu

Po kazdej inspekcji przeprowadzana jest analiza projektu pod katem kosztow, zuzytego czasu realizacji, prognozy co do terminu zakonczenia projektu oraz sensownosci dalszego prowadzenia projektu.

Rozdzial 7. Plan testowania oprogramowania

Klasyfikacja bledow

  • Funkcjonalne

    Funkcja zle wykonana badz zle funkcjonujaca

  • Systemowe

    nieprawidlowe zarzadzanie zasobami, mylne interfejsy, zla komunikacja z baza danych badz jej brak

  • Przetwarzania

    niewlasciwe przetwarzanie danych w poszczegolnych modulach

  • Danych

    zle wprowadzone dane, ich brak, bledna specyfikacja

  • Graficzne

    interfejs graficzny niezgodny z zalozeniami

  • Kodowania

    niewlasciwe uzycie jezyka programowania

  • Dokumentacji

    niepelna lub bledna dokumentacja

  • Inne

    niezidentyfikowana przyczyna wystapienia

Lista testow

  • Analiza kodu

  • Testy funkcjonalne poszczegolnych modulow systemu

    Przetestowana szczegolowo zostanie kazda funkcja systemu wynikajaca z dokumentacji. Ocenione zostana: obecnosc (lub nieobecnosc funkcji), poprawnosc jej dzialania oraz szybkosc dzialania. W przypadku braku funkcji lub nieprawidlowego dzialania nalezy wprowadzic poprawki. Jesli funkcja dziala zbyt wolno (oczekiwany i maksymalny czas reakcji - patrz dokumentacja odpowiednich funkcji) zalecana jest optymalizacja.

  • Test porownawczy wynikow otrzymanych z oczekiwanymi

    Ze wzgledu na koniecznosc wspolpracy ze soba wszystkich modulow systemu przyjmujemy model testowania zstepujacego.

  • Testy obciazenia

    Wykonany na maszynie z minimalna konfiguracja sprzetowa, oraz konfiguracjami bardziej rozbudowanymi. Na podstawie otrzymanych wynikow przeprowadzamy ocene przypuszczalnej wydajnosci systemu na platformie docelowej.

  • Testy odpornosciowe

    Podczas testow zostanie wywolana seria sytuacji awaryjnych (wylaczenia pradu, restarty systemu, znanaczne zwiekszenie obciazenia serwera), zarowno w czasie "typowego" jak i "nietypowego" dzialania systemu. Po przywroceniu normalnej pracy systemu zostanie w kazdym przypadku przeprowadzona szczegolowa analiza skutkow sytuacji.

  • Test zuzycia zasobow przez system

    Przeprowadzone rownolegle z testem wydajnosci systemu za pomoca firmowego oprogramowania monitorujacego. Na podstawie otrzymanych wynikow przeprowadzamy ocene przypuszczalnego zuzycia zasobow na platformie docelowej.

  • Testy wydajnosci

  • Testy niezawodnosci

    Niezawodnosc oceniona zostanie na podstawie wynikow ankiet wypelnianych przez testujacych w pozostalych testach, jak rowniez analizy dziennikow tworzonych automatycznie przez system podczas tych testow. Ponadto przez pierwsze 3 miesiace po wdrozeniu systemu przedstawiciele firmy beda prowadzili dalsze analizy niezawodnosci (rownolegle z analiza pozostalych parametrow pracy systemu).

  • Test bezpieczenstwa

    Kontrola dwuetapowa. W pierwszym etapie probe zlamania zabezpieczen systemu przeprowadzi zespol firmowy, w drugim wynajeta specjalistyczna firma.

  • Test ergonomii interfejsu

    Ocena zgodnosci wykonanego interfejsu z projektami zatwierdzonymi przez uzytkownika przez dwa zespoly - firmowy oraz niezalezny. Pozadany udzial przedstawicieli zamawiajacego w jednym (lub obu) zespolach. Poza zgodnoscia wykonania zespol firmowy oceni rowniez spojnosc interfejsu.

  • Testy funkcjonalne uruchamiania i dzialania procesow

  • Testy modyfikowalnosci oprogramowania

    Dwa firmowe zespoly programistow nie zwiazane z implementacja tego systemu otrzymaja polecenie wprowadzenia poprawek do dzialania kilku z funkcji systemu oraz uzupelnienia systemu o dodatkowe funkcje. W wypadku braku wolnych zespolow w tym czasie mozliwe jest zlecenie tego wykonawcy zewnet rznemu (choc nie jest to zalecane ze wzgledu na wyzsze koszty). Po zakonczeniu modyfikacji zespoly te wypelnia ankiety sluzace do oceny latwosci wprowadzenia zmian, dzialanie zas samych modyfikacji, jak rowniez reszty systemu zostanie ponownie przetestowane (tylko na poprawnosc dzialania). Przypuszczalnie zostana przeprowadzone dodatkowe "testy" ze wzgledu na zmiane wymagan przez uzytkownika w trakcie realizacji systemu.

  • Testy skalowalnosci systemu

    Przeprowadzana razem z testem zuzycia zasobow, na podstawie tych samych danych, uzupelnionych o czas reakcji systemu oceniany przez uzytkownika. Dane uzyskane podczas testu zostana przeanalizowane pod katem pracy systemu przy duzych obciazeniach.

  • Testy alfa

    Przeprowadzona w formie odbioru systemu przez przedstawicieli uzytkownika. Przedstawiciele dostaja wolna reke w testowaniu systemu, pelna pomoc personelu firmy. Wynikiem testu bedzie ocena systemu wystawiona przez przedstawicieli uzytkownika.

  • Przeglad jakosci dokumentacji

    Test zostanie przeprowadzony w formie szkolenia przyszlych uzytkownikow systemu. Po zakonczeniu szkolenia wypelnia oni ankiete przeznaczona do oceny jakosci materialow dydaktycznych. Nastepnie zostanie przeprowadzona symulacja rzeczywistych dzialan przy uzyciu systemu. Zespol firmowy (ew. uzupelniony o przedstawicieli klienta - b. pozadane) oceni jakosc dzialan pracownikow, a co za tym idzie ich stopien przygotowania do pracy. Na podstawie tych danych zostanie oceniona dokumentacja systemu oraz sam proces szkolenia.

Harmonogram

  • Testy modulow

    Testy te zostana przeprowadzone w fazie implementacji, po zakonczeniu realizacji poszczegolnych modulow.

  • Testy systemu

    Testy przeprowadzane po integracji modulow. System jest juz testowany jako spojna calosc.

  • Testy akceptacji (testy alfa)

    Test przeprowadzany przez koncowych uzytkownikow systemu.

Scenariusze akceptacji

Ze wzgledu na specyfike testow, przygotowanie poszczegolnych testow funkcjonalnosci zostalo podzielone wedlug aktorow wystepujacych w systemie.

  1. pracownik dzialu kadr

    • Przygotywywanie testow

    • Ustalanie parametrow testow

    • Przeprowadzanie testow

    • Przygotowywanie raportow

    • Generowanie analiz potrzeb personalnych

    • Przypisywanie pilotow do lotow

  2. pracownik dzialu logistyki

    • Przygotowywanie faktur

    • Ustalanie automatyki zamowien

    • Wprowadzanie danych o sprzecie

  3. pracownik placowki handlowej

    • Publikacja informacji na stronach internetowych

    • Dostep do danych o lotach

  4. klient

    • Rezerwacja biletow

Rozdzial 8. Oszacowanie zlozonosci oprogramowania

Nie skorygowane punkty funkcyjne

Typ Zlozonosc Suma
Niska Srednia Wysoka
Wejscia uzytkownika 19 * 4 15 * 5 13 * 6 229
Wyjscia uzytkownika 19 * 5 15 * 6 13 * 7 276
Zbiory danych wewnetrzne 20 * 5 15 * 10 20 * 15 550
Zbiory danych zewnetrzne 5 * 5 2 * 7 2 * 9 57
Zapytania zewnetrzne 9 * 4 5 * 6 2 * 8 82
Suma nie skorygowanych (UFP) 1194

Korekcja punktow funkcyjnych

Nr Ogolna charakterystyka sytemu Punkt
1. Wystepowanie urzadzen komunikacyjnych 3
2. Rozproszenie przetwarzania 1
3. Wymagane parametry szybkosci dzialania 2
4. Skomplikowana logika przetwarzania 1
5. Obciazenie systemu - liczba transakcji 4
6. Wprowadzanie danych w trybie online 4
7. Wydajnosc uzytkownika koncowego 2
8. Aktualizacja danych w trybie online 3
9. Rozproszenie terytorialne 4
10. Zlozonosc przetwarzania danych 2
11. Przenosnosc 5
12. Prostota instalacji 1
13. Prostota obslugi 3
14. Zmiany w okresie eksploatacji 1
Suma (VAF) 36

Rezultat koncowy

VAF = 36

FP = (0.65 + 0.01*VAF) * UFP

FP = 1.01 * 1194 = 1205.94

Szacowanie koniecznych nakladow

1205.94 punktow funkcyjnych odpowiada pracochlonnosci okolo 120 osobomiesiacom.