<Police Station Manager>

Plan zapewnienia jakości

Wersja <1.1>

Historia dokumentu

Data	Wersja	Opis	Autor
< 2006/listopad/14 >	<1.0>	Uzupełnienie informacji na temat Planu Zapewnienia Jakości	Pożarski
<2006/listopad/30>	<1.1>	Przypisanie nazwisk, dat, lokalizacji dokumentów poszczególnych osób do swoich zadań w projekcie	Pożarski

Spis treści

1. Wstęp

Plan zapewnienia jakości

1. Wstęp

1. Cel

Celem tego dokumentu jest zapewnienie dobrej jakości dla powstającego systemu zarządzania Komisariatem Policji. Plan zapewnienia jakości obejmuje wszystkie etapy prac nad projektem zaczynając od fazy analizy aż do fazy wdrożenia, a także wszystkie produkty wytworzone podczas pracy nad tym systemem.

2. Zakres

Dokument opisuje plan zarządzania jakością

3. Definicje, akronimy, skróty

[Sekcja zawiera definicję wszystkich terminów, akronimów oraz skrótów niezbędnych do właściwego zrozumienia dokumentu.. Informacje zawarte tutaj mogą być odnośnikami do Słownika projektu.]

4. Dokumenty powiązane

Dla Planu Zapewnienia Jakości lista referencji zawiera:

• Plan Dokumentacji - Jacek Korwin-Małaszyński / 15 listopada 2006 / nuemr raportu / Turbo Janki /

Link do źródła dokumentu: http://io.pjwstk.edu.pl/byt/Default.aspx?g=posts&t=144

• Plan Testów - Krzysztof Falatowicz / brak /

Link do źródła dokumentu: brak

• Plan Zarządzania Projektem - Michał Gniazdek / 15 listopada 2006 / nuemr raportu / Turbo Janki /

Link do źródła dokumentu: http://io.pjwstk.edu.pl/byt/Default.aspx?g=posts&t=144

• Plan Zarządzania Konfiguracją - Julian Papiński / brak / nuemr raportu / Turbo Janki /

Link do źródła dokumentu: brak

• Plan Komunikacji w Projekcie - Marcin Olech / brak / nuemr raportu / Turbo Janki /

Link do źródła dokumentu: brak

• Plan Oszacowania Złożoności Projektu - Jakub Pawlik / brak / nuemr raportu / Turbo Janki /

Link do źródła dokumentu: brak

5. Organizacja dokumentu

[Ta sekcja zawiera opis pozostałej części dokumentu oraz opisuje strukturę dokumentu.]

1. Cele jakości

[Sekcja zawiera odniesienia do pozycji Specyfikacji Wymagań związanych z jakością.]

2. Zarządzanie

1. Organizacja

Kierownik projektu (Standardy komunikacyjne / Plan działań) - Michał Gniazdek

Analityk (Dokument def. wymagań oraz szacowanie złożoności projektu) -Jacek Małuszyński, Jakub Pawlik

Projektant (Plan zapewnienie jakości, Zarządzanie konfiguracją) - Maciej Pożarski, Julian Papiński

Programista (Odpowiedzialny za plan testów) - Krzysztof Falatowicz

Dokumentacja (Standardy komunikacyjne) - Marcin Olech

2. Zadania i odpowiedzialności

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.

Zadania:

• tworzenie standardów

• wdrażanie standardów

• ocena produktu

• ocena procesu

• zatwierdzenie jakości

• zbieranie danych

• analiza danych

Odpowiedzialności:

KIEROWNIK PROJEKTU:

- Szacowanie czasu i budżetu projektu

- Sporządzenie harmonogramu zadań ( ustalenie kalendarza prac, podział przedsięwzięcia na poszczególne zadania, określenie zasobów potrzebnych do realizacji, określenie kolejności i czasu wykonywania poszczególnych zadań)

- Podział zadań pomiędzy wykonawców" i ich koordynacja

- Śledzenie postępu realizacji w ramach przyjętego planu

- Dostosowanie planu realizacji projektu do zmieniającej się sytuacji

- Składanie raportu o wynikach prac

ANALITYK:

Jest to osoba mająca bezpośredni kontakt z klientem/użytkownikami przyszłego systemu.

Jego zadaniem jest określenie wymagań i budowa modelu systemu.

- Określenie wszystkich funkcji realizowanych przez system - w tym celu analityk

przeprowadza wywiad z przyszłymi użytkownikami systemu. Często jednak użytkownik nie posiada wiedzy na temat możliwości oferowanych przez różne narzędzia i nie jest w stanie sam jasno sprecyzować wymagań. Analityk musi „wydobyć" je z użytkownika.

- Studiowanie środowiska systemu (studiowanie podręczników użytkowania istniejących systemów komputerowych, obserwacja pracy wykonywanej dotychczas bez wspomagania systemu komputerowego)

- Dokumentacja wymagań - opis wymagań funkcjonalnych (operacje wykonywane przez system) oraz niefunkcjonalnych (ograniczenia, przy których system powinien realizować funkcje), sporządzanie słownika pojęć i diagramów przypadków użycia

- Analiza i konsolidacja wymagań (usuwanie sprzeczności i nadmiarowości)

PROJEKTANT:

Osoba odpowiedzialna za realizację oprogramowania.

Przygotowuje szczegółowy opis implementacji systemu w oparciu o wymagania dostarczone przez analityków - praca projektanta jest silniej związana z narzędziami do wytwarzania oprogramowania

- Uszczegółowienie wyników analizy - czyli wybór sposobu implementacji konstrukcji zawartych w modelu (poprawki w diagramach, określenie typów danych)

- Dostosowanie systemu do ograniczeń środowiska implementacji, np. braku dziedziczenia czy metod wirtualnych.

- Opracowanie składowych programu, które nie realizują podstawowych zadań systemu. Funkcje te są konieczne do prawidłowego działania systemu, nie znajdują się jednak w wymaganiach - ( projekt interfejsu użytkownika, sposób przechowywania trwałych danych, zarządzanie pamięcią i czasem procesora)

W zależności od wielkości przedsięwzięcia funkcje: analityka, projektanta i programisty są łączone:

Analityk/projektant i programista - osoba kontaktująca się z klientem przygotowuje nie tylko wymagania, ale również projekt oprogramowania. W takim przypadku od programisty nie wymaga się dużego poziomu zaawansowania

Analityk i projektant/programista - Osoba kontaktująca się z klientem przygotowuje wvmasama- model systemu i co najwyżej wykonuje projekt wysokiego poziomu. Inne osoby są odpowiedzialne za przy gotowanie szczegółowego projektu i implementację

oprogramowania.

PROGRAMISTA:

Osoba implementująca oprogramowanie. W zależności od podziału ról może zajmować się też projektem systemu.

OSOBA WYKONUJĄCA TESTY

- Wykrycie błędów w systemie

- Ocena niezawodności systemu - w tym celu prowadzi się testy statystyczne, pozwalające określić przyczynę najczęstszych błędnych wykonań

Podział testów ze względu na technikę wykonywania:

Tester może wykonywać testy dynamiczne polegające na uruchamianiu fragmentów

programu i porównywaniu wyników z wynikami poprawnymi, oraz-testy statyczne, oparte- na analizie kodu (dowody poprawności, metody nieformalne).

Testy pod obciążeniem - zbadanie wydajności pod pełnym lub nadmiernym obciążeniem (dotyczy zwłaszcza systemów sieciowych)

Testy odporności - sprawdzenie działania w przypadku zajścia niepożądanych zdarzeń (zanik zasilania, wprowadzenie niepoprawnych danych, wy danie sekwencji niepoprawnych poleceń)

OSOBA ODPOWIEDZIALNA ZA KONSERWACJĘ OPROGRAMOWANIA

EKSPERT METODYCZNY - osoba szczególnie dobrze znająca stosowaną metodykę

EKSPERT TECHNICZNY - osoba szczególnie dobrze znająca obsługę narzędzi

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

• dla fazy wymagań użytkownika i analizy;

• dla fazy projektu architektury;

• dla fazy projektowania i konstrukcji;

• dla fazy budowy, testowania i instalacji oprogramowania.

- Formularz wymagań funkcjonalnych

- Formularz zapisu wymagań

- Weryfikowalność wymagań niefunkcjonalnych

- Słownik

- Dokument wymagań na oprogramowanie

- Poprawiony dokument opisujący wymagania

- Dokument opisujący stworzony projekt

- Raporty z informacjami o testowaniu produktu, jego błędach, możliwości modyfikacji, opinie niezależnych kontrolerów, przyszłych użytkowników.

4. Metryki

Funkcjonalność

• stopień realizacji wymagań funkcjonalnych - określa w jakim stopniu zostały spełnione założone wstępne wymagania funkcjonalne. Tzn. będzie sprawdzana: odpowiedniość, dokładność, współdziałanie, zgodność, bezpieczeństwo. Miarą funkcjonalności jest „s” podawane w procentach i wyliczany stosunek wykonanych funkcjonalności do tych założonych

Niezawodność

• stopień niezawodności - określa w jaki sposób produkt spełnia pewne cechy określane poprzez niezawodność. Należą do nich: dojrzałość, tolerancja błędów, odtwarzalność. Miarą funkcjonalności jest wartość ważona obliczana ze wzoru :

gdzie:
Za D (dojrzałość) przyjmujemy wartość z przedziału 0-1, gdzie ocenianymi miarami są : współdziałanie z użytkownikiem - 30% wartości, łatwość wprowadzania zmian (modyfikacji reakcji systemu na błędy i inne przypadki) - 70% wartości.

Za O (odtwarzalność) przyjmujemy wartość od 0-1 w zależności od interwału czasowego po jakim jest naprawiana awaria systemu (odtworzenie danych sprzed awarii) . Wartość większa od 0.5 oznajmia iż interwał jest krótszy od 1 godziny. Prędkość narastania wartości O jest ustalany według potrzeb użytkownika

Za Tb (Tolerancja błędów) przyjmujemy wartość 0-1 w zależności od zachowania się systemu w przypadku pojawienia się błędu. Jest to krytyczna składowa tej funkcjonalności. Wartość poniżej 0.7 (oznaczająca obsługę błędów nieprzewidzianych i możliwość szybkiej modyfikacji reakcji systemu na nieobsługiwane błędu)praktycznie dyskwalifikuje system jako System bezpieczny. Wartość 1 jest wartością nieosiągalną dla jakiegokolwiek systemu, oznacza ona iż system jest całkowicie odporny na wszelkie błędy.

Wartości m i p są wartościami warzonymi w zależności od potrzeb systemu i klienta, jednak nie mniejszymi od 2.

Aby ustalić końcową miarę funkcjonalności należy obliczyć maksymalną wartość funkcjonalności wynoszącą MFmax = 1 + 1/m + 1/p, podstawiając odpowiednie wartości pod m i p. Po obliczeniu MFmax, należy obliczyć MF systemu według wzoru MF. Stosunek MF/MFmax określa miarę końcową niezawodności.

Stosunek MF/MFmax poniżej 0.85 dyskwalifikuje system jako system niezawodny

5. Plan przeglądów i audytów

Przeglądy i audyty

Identyfikuje techniczne przeglądy, przejścia, inspekcje, audyty mające zastosowanie w tej fazie, oraz cel każdego z nich. Opisuje sposoby monitorowania zgodności tych procedur z planem oraz rolę personelu ZJO w tych procedurach.

Procedury te są wykonywane w celu sprawdzenia zespołu projektowego pod kontem przygotowania merytorycznego jak i technicznego niezbędnego do realizacji projektu.

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.

Narzrzędzia, techniki i metody

Podczas tworzenia dokumentacji, użyte zostanie narzędzie, wspomagające tworzenie diagramów UML. Wszystkie dokumenty oparte będą na formacie HTML, tak aby każdy, niezależnie od środowiska pracy, mógł je przeczytać.

6. Weryfikacja i testy

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

7. Narzędzia, techniki, metodyki

Podczas tworzenia dokumentacji, użyte zostanie narzędzie, wspomagające tworzenie diagramów UML. Wszystkie dokumenty oparte będą na formacie HTML, tak aby każdy, niezależnie od środowiska pracy, mógł je przeczytać.

8. Zarządzanie konfiguracją

Zarządzanie konfiguracją w projekcie jest opracowane przez Juliana Papińskiego

9. Kontrola nad dostawcami i podwykonawcami

Nie dotyczy

10. Szkolenia

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.

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

< Turbo Janki>

< Police Station Manager>	Wersja: <1.1>
Wizja Projektu	Data: <2006/listopad/14>
<01200452505>

Tajne

©< Turbo Janki>, 2006

Strona 4 of 10

---