Dokumentacja w zapewnieniu jakości w projektach wdrożeniowych

W procesie realizacji projektów informatycznych wykorzystywane są różne metodyki, z których każda posiada swoje standardy dokumentacyjne. Jednym z elementów zapewniających odpowiednią jakość wdrożenia systemu jest oprócz dokumentacji systemu jest opracowanie schematu dokumentów, które powstają w różnych etapach realizacji procesu wdrożenia, np. w metodyce IBM wykorzystywana jest książka kontrolna projektu o jednorodnej wersji i standardowych formularzach.

Odpowiedni system dokumentujący gwarantuje kompletność i jednoznaczność, zapewnia sprawną komunikację między klientem a zespołem wdrożeniowym oraz wewnątrz zespołu, jak również daje możliwość prowadzenia kilku wersji. Jednolity schemat dokumentacji umożliwia zapisanie podjętych decyzji, ich uzasadnienie oraz stanowi punkt odniesienia dla oceny realizacji prac.

Należy zauważyć, że tworzenie dokumentów nie może stać się głównym celem projektu, a ma być narzędziem wspomagającym proces jego zarządzania.

Schemat dokumentacji powinien obejmować wszystkie grupy dokumentów związane ze wszystkimi fazami procesu tj: dostawą i instalacją oprogramowania oraz głównymi i dodatkowymi usługami wdrożeniowymi. W celu uniknięcia nieporozumień i dla prawidłowego przebiegu procesu należy opracować ujednolicony schemat korespondencji z klientem.

Wśród dokumentów dotyczących dostawy oprogramowania jako najistotniejsze należy uznać dokumenty opisujące przedmiot i istotne warunki dostawy oprogramowania oraz protokół dostarczenia produktu informatycznego.

Głównym etapem projektu wdrożeniowego etapem jest wykonanie usług wdrożeniowych. Jest to etap, który wymaga szeregu bardzo istotnych dokumentów wśród których należy wymienić:

■ dokument definiujący projektu,

■ projekt rozwiązania,

■ potwierdzenie dostarczenia i instalacji niezbędnego oprogramowania,

■ specyfikację ewentualnych modyfikacji,

■ protokoły odbioru usług, zatwierdzenia punktów kontrolnych i zakończenia.

Dokument definiujący projekt to jeden z głównych dokumentów określający cel główny i opis projektu, przedstawiający organizację projektu, metody śledzenie i kontrola projektu, specyfikację prac technicznych oraz zasady dokumentacji.

Zawarty w dokumencie definicji opis projektu to przede wszystkim określenie najważniejszych celów projektu, zakres funkcjonalny wdrożenia, podział wdrożenia na etapy oraz budżet. Jest to również dokument zawierający ramowy plan projektu, jego harmonogram, plan kamieni milowych jak również pożądane efekty poszczególnych etapów.

Nie mniej istotne są dokument}' dotyczące organizacji projektu. Dokumenty

te powinny przedstawić komitet sterujący: sponsora projektu, przedstawicieli klienta, przedstawicieli firmy wdrożeniowej, pozostałe osoby wchodzące w skład komitetu oraz zespoły wdrożeniowe (kierownicy, członkowie, konsultanci wiodący, pozostali konsultanci).

Do części organizacyjnej należą również dokumenty dotyczące śledzenia i kontroli projektu, które powinny zawierać podstawowe informacje dotyczące zarządzania projektem takie jak:

■ terminarz okresowych spotkań komitetu sterującego,

■ sposób koordynacji wewnętrznej w projekcie,

■ metody i hierarchię komunikacji,

■ sposób zatwierdzenie punktów kontrolnych i kamieni milowych,

■ metody rozwiązywania konfliktów.

Siedzenie kontrola projektu powinny między innymi określać formę wszystkich dokumentów takich jak raporty ze spotkań, agendy, notatki spotkań. Dla dokumentów tych należy określić szablony zawierające przynajmniej następujące informacje:

■ data,

■ wersja,

■ czas trwania,

■ uczestnicy,

■ cel,

■ omówione zagadnienia i podjęte decyzje,

* termin następnego spotkania,

■ podpisy ze strony firmy wdrożeniowej i klienta,

■ oraz informacje o adresatach dokumentu.

Kolejna istotna grupa są dokumenty dotyczące projektu rozwiązania.

Dokumenty te powinny dla każdego wydzielonego fragmentu systemu np. procesu przedstawiać:

* nazwę procesu lub usługi,

■ cel,

■ opis,

* scenariusz działań,

■ mapę procesu, procesy poprzedzające, procesy korzystające,

* dane podstawowe dla obsługi procesu,

■ raporty wykorzystywane w obsłudze procesu (standardowe lub dodatkowe),

■ uprawnienia do obsługi procesu,

■ zmiany organizacyjne niezbędne do implementacji procesu,

■ wymagane modyfikacje i interfejsy z systemami zewnętrznymi,

■ metody migracji danych.

W przypadku realizacji modyfikacji oprogramowania należy również wprowadzać szczegółowa dokumentację określającą projekt funkcjonalny zawierający specyfikację funkcjonalną (cel zakres, ograniczenia, załączniki) oraz uzgodnienia z klientem dotyczące wyceny i zatwierdzenia zakresu.

Tworząc rozwiązanie informatyczne należy zawsze mieć na uwadze cel

projektu, dokumentacja jest tylko jednym z narzędzi, wspomagających jego osiągnięcie i zapewniających określony poziom jakości. Należy również zauważyć, że jeśli firma wdrażająca system lub jej klient posiada certyfikaty jakości np. ISO, wtedy znaczna część dokumentacji wynika z wymaganych przez nie zapisów.

Wnioski

Z punktu widzenia technologii, wszystkie firmy m ają dzisiaj praktycznie ten sam poziom wyposażenia sprzętowego, wydajność systemów projektowania oprogramowania jest porównywalna, a projektanci i programiści korzystają z tych samych narzędzi dostarczanych przez kilkadziesiąt wiodących na rynku firm. To co może różnicować firmy to czynnik ludzki, kultura organizacyjna, efektywny system procesów produkcyjnych oraz wdrożony i skuteczny proces ciągłego doskonalenia.

Zarządzanie jakością nie polega na korzystaniu ze specjalnych narzędzi, przeprowadzaniu przełomów organizacyjnych i zdobywaniu certyfikatów jakości.

Jego istotą jest zmiana kultury organizacyjnej firmy. Zamiast koncentrować się na zysku - nastawiamy się na jakość produktów. Nawet, jeśli miałoby nas to więcej kosztować teraz, przyniesie większe zyski później. Aby to podejście zrozumieć i mieć odwagę wdrożyć w firmie potrzeba dojrzeć do pełnego i dorosłego widzenia korzyści, jakie niesie ono dla firmy w perspektywie strategicznej, a nie tylko krótko terminowej. Jest to skomplikowane, ale realne.

Jakość powstaje nie w wyniku badania gotowego produktu - testów, ale w wyniku wbudowania jej w produkt na każdym etapie procesu wytwórczego. W sytuacji idealnej testowanie w ogóle przestaje być potrzebne - gwarantem jakości jest jakość systemu wytwórczego. Zmiana projakościowa systemu wytwórczego nie następuje jako wynik uporządkowania pojęć związanych z zarządzaniem jakością.

Nie ogranicza się do ukonstytuowania pewnych reguł, zasad, systemów, szablonów.

Jest procesem kształtowania kultury firmy. Każda firma przechodzi pew ną ewolucję, dojrzewa do rozumienia nie tylko procesów tynkowych i wytwórczych, ale także tych, które zmierzają do zapewnienia właściwej jakości dostarczanych produktów.

Skuteczne zarządzanie jakością, które ma prowadzić do wypracowania przewagi konkurencyjnej na rynku nie może obejść się bez przemyślanego określenia polityki jakości, zarządzania zasobami ludzkimi, środowiskiem pracy, wymaganiami klienta..

Jest to długotrwały proces, którego pozytywne skutki widoczne są dopiero po pewnym czasie i może dlatego tak trudno zdecydować się nań tym, którzy oczekują natychmiastowych wyników.

Analiza wymagań i testowanie są bardo ważnymi i kosztownymi etapami w projekcie powstawania czy wdrażania systemu informatycznego, dlatego też należy do nich podejść ze szczególną, inżynierską pieczołowitością i zastosować najefektywniejsze narzędzia do ich realizacji.

L ite ra tu ra

1. Byzia T.: artykuł Zarządzanie jakością oprogramowania. Część 1: Jakość.

Computer World nr 8, 1998.

2. Byzia T.: artykuł Zarządzanie jakością oprogramowania. Część 2:

Terminologia. Computer World nr 9, 1998.

3. Byzia T.: artykuł Zarządzanie jakością oprogramowania. Część 3: Filozofia.

Computer World nr 10, 1998.

4. Byzia T.: artykuł Zarządzanie jakością oprogramowania. Część 5: Kryteria.

Computer W orld nr 12, 1998.

5. Byzia T.: artykuł Zarządzanie jakością oprogramowania. Część 6: Testowanie.

Computer World nr 13, 1998.

6. Byzia T.: artykuł Zarządzanie jakością oprogramowania. Część 7: Narzędzia.

Computer W orld nr 14, 1998.

7. Byzia T: Zarządzanie jakością w projekcie informatycznym. M ateriały z warsztatów po XI Konferencji Górskiej Szkoły PTI „Jakość systemów informatycznych problemy i rozwiązania”, Szczyrk, 1999.

8. Norma IEEE Std 730.1-1995. Wytyczne do tworzenia planu zapewnienia jakości.

9. Szyjewski Z.: Zarządzanie projektami informatycznymi. M etodyka tworzenia systemów informatycznych. Agencja wydawnicza Placet, W arszawa, 2001.

V , .

R O Z D Z IA Ł V II