Czym jest jakość? Według najbardziej

Transkrypt

1 Są to cechy istotne z punktu widzenia konsumenta. Producent musi oprócz tego brać pod uwagę zyskowność i działalność konkurencji, co często jest w konflikcie z jakością technologiczną produktu. Bardzo często zdarza się, iż w trakcie produkcji wyrobu pojawiają się różnego rodzaju niezgodności i odchylenia od projektowanej jakości. Zgodnie z normą ISO 9001:2000 organizacja powinna sprawować nadzór nad wyrobem Czym jest jakość? Według najbardziej znanych definicji, jakość to: zgodność z wymaganiami P.B. Crosby wszystko co można poprawić Masaaki Imai ogół cech i właściwości wyrobu lub usługi, które decydują o zdolności wyrobu lub usługi do zaspokajania stwierdzonych i przewidywanych potrzeb ISO 8402 Norma ISO 9001:2000 określa jakość jako stopień, w jakim zbiór inherentnych cech spełnia wymagania. W tym kontekście jakość oznacza: zgodność ze specyfikacją i celem oraz zespół cech i charakterystyk wyrobu lub usługi, które noszą w sobie zdolność zaspokojenia określonych potrzeb. Dość często jakość postrzegana jest przez pryzmat jakości technologicznej w aspektach funkcjonalności, praktyczności, niezawodności, trwałości oraz bezpieczeństwa użytkowania. Z drugiej strony, jakość może być charakteryzowana wskaźnikami rynkowymi takimi jak: stopień zgodności z wzorcem lub zdefiniowanymi wymaganiami, widoczność zespołu cech istotnych dla produktu, ekskluzywność, estetyczność, prezentacja, koszt nabycia bądź usatysfakcjonowanie użytkownika, czyli zaspokojenie potrzeb i oczekiwań nabywcy. 1

2 niezgodnym. W IT takim wyrobem jest system informatyczny oraz pozostałe wytwory procesu produkcji oprogramowania. Głównym wytworem przedsięwzięcia informatycznego jest produkt system informatyczny. Produkt informatyczny z racji swojego zróżnicowania oraz wielu możliwych punktów widzenia może być charakteryzowany różnymi definicjami jakości (ramka nr 1). Różnorodność podejść do problemu jakości oprogramowania przejawia się w strukturze norm i standardów odnoszących się do przypadku oprogramowania dostarczonego (jakość zewnętrzna), do przypadku rezultatów projektowania (jakość wewnętrzna), do czynności opracowywania, do procesów opracowywania i do systemu jakości. Jakość postrzegana przez użytkownika oprogramowania dotyczy bezpośrednich własności dostarczonego oprogramowania oraz usług to- 2

3 warzyszących zakupowi wynikających z umowy (pomoc techniczna, szkolenie, itp.). Normy standardy jakości dzielą się na grupy, zależnie od obszaru i procesu projektowania oprogramowania, którego dotyczą (Rys. 1). Norma ISO obejmuje ogólny system jakości w przedsiębiorstwie. Aby wymagania normy zostały spełnione, konieczne jest usystematyzowanie i udokumentowanie określonych obszarów. Obszary te zostały przedstawione na schemacie podejścia procesowego (rys. 2). Zgodnie z wymaganiami normy ISO 9001 proces wytwarzania wyrobu lub usługi powinien obejmować sposób postępowania z produktem niezgodnym. Norma ISO 9001 mówi o tym w punkcie 8.3. Nadzór nad wyrobem niezgodnym (ramka). Zgodnie z powyższym punktem organizacja posiadająca wdrożony System Zarządzania Jakością ISO 9001 powinna umieć zidentyfikować niezgodność produkowanego wyrobu z wymaganiami klienta i podjąć odpowiednie kroki w reakcji na zaistniałą niezgodność. Działania te mają na celu wyeliminować, lub zminimalizować, ryzyko dostarczenia klientowi wyrobu, który nie spełnia w pełni określonych wymagań. W przypadku przedsiębiorstwa zajmującego się wytwarzaniem oprogramowania, nadzór nad produktem niezgodnym występuje na trzech etapach realizacji projektu informatycznego: w fazie analizy i projektowania, w fazie produkcji, po wdrożeniu systemu na produkcję. Każdy wymieniony etap projektu ma nieco inny cel. Inne są też produkty i w związku z tym należy stosować odmienne metody i techniki nadzoru nad niezgodnościami. W pierwszej kolejności omówimy przykładowy proces nadzoru nad produktem niezgodnym na etapie analizy i projektowania systemu. Etap analizy projektowej zwany też modelowaniem wymagań klienta ma na celu pozyskanie i udokumentowanie wymagań nabywcy oprogramowania oraz zaprojektowanie systemu IT. Faza ta z reguły wiąże się z wysokim ryzykiem pominięcia lub zniekształcenia pewnych wymagań zamawiającego produkt informatyczny. Niezgodność na tym etapie dotyczy głównie dokumentacji projektowej i może wyrażać się poprzez: Udokumentowanie niepełnych wymagań tj. wymagania uzyskane od klienta nie obejmują całości planowanej funkcjonalności systemu. Klient może zakładać, iż pewne wymagania są oczywiste i nie ma potrzeby ich dokumentacji lecz w praktyce większość takich kwestii jest pomijana i nie uwzględniona w projekcie systemu. Zleceniodawca może też po prostu nie wiedzieć, iż powinien wyspecyfikować lub przynajmniej zasygnalizować pewne informacje nie jest wszak (zazwyczaj) informaty-

4 kiem i nie orientuje się, że aby stworzyć spójny oraz kompletny system informatyczny należy określić jego założenia na odpowiednim poziomie szczegółowości. Pominięcie wymagań w dokumentacji wynikające z błędu człowieka. Analityk również może popełniać pomyłki nie zrozumieć oczekiwań klienta, bądź zrozumieć je opacznie, niepoprawnie udokumentować wymagania naruszając spójność i kompletność całości dokumentacji analitycznej. Dość często ryzyko to wiąże się się z odkładaniem realizacji zadań na później. Podczas fazy analizy biznesowej zdarzają się momenty (lub dłuższe okresy) wzmożonej pracy metodą na to może być wykonywanie zadań o najwyższym priorytecie w pierwszej kolejności, a pozostawianie innych w formie zapisów czy notatek (tak zwanych TO DO) do uszczegółowienia w przyszłości. Metoda ta sprawdza się w przypadku, gdy owe notatki prowadzone są w sposób przejrzysty i dobrze uporządkowany w przeciwnym razie łatwo o pomyłkę i pominięcie pewnych informacji przy kontynuowaniu prac dokumentacyjnych. Brak zgodności z wymaganym wzorem dokumentacji z reguły każdy analityk tworzy dokumentację według swego własnego szablonu, nie stosując się do wymagań ogólnego, ustalonego przez przedsiębiorstwo wzorca. Wskutek tego część elementów istotnych dla kompletności i spójności wymagań może zostać pominięta. Dodatkowo, niespójna dokumentacja projektowa brak ustalonej, wspólnej konwencji nie przekłada się na wysoką jakość produktu, jakim jest specyfikacja funkcjonalna oprogramowania. Stosowanie szablonów powinno na stałe wejść do praktyki twórców dokumentacji ułatwia pracę nie tylko im samym (umożliwiając kontrolę efektów własnej pracy z wymaganiami szablonu), ale i pozostałym członkom zespołu projektowego (programistom ponieważ nie uczą się struktury każdego dokumentu od początku i nie gubią się w treści; testerom jako, że łatwiej im później dokonać przeglądu dokumentacji oraz projektować przypadki testowe). 4

5 5

6 Produkt etapu analizy projektowej dokumentacja analityczna i wszelkie specyfikacje techniczne oraz prototypy UI projektowanego systemu podlega takim samym zasadom kontroli jakości oraz zarządzania produktem niezgodnym jak kluczowy wytwór procesu produkcji oprogramowania system informatyczny. Dokumentacja zarówno ta używana do celów wewnętrznych (rozwoju aplikacji oraz testowania), jak i dostarczana wraz z produktem informatycznym nabywcy oprogramowania, powinna spełniać określone wymagania. Najbardziej istotne wśród nich to: spójność; kompletność; zgodność z wymaganiami; jednoznaczność; możliwość weryfikacji; przejrzystość i czytelność. W jaki sposób zapewnić, że niezgodności na etapie analizy są zidentyfikowane i wyeliminowane? Najprostszym sposobem są przeglądy dokumentacji (audyty nieformalne). Przegląd ma na celu wykrycie, analizę a następnie poprawienie wszelkiego typu błędów, luk i nieścisłości w dokumentacji na możliwie wczesnym etapie projektu. Przegląd, aby był skuteczny i spełniał swoją rolę, powinien zostać odpowiednio zaplanowany i zorganizowany. Czynności związane z przeglądem należy uwzględnić w planie projektu podejście typu ad hoc nie jest wskazane, jako że uniemożliwia wprowadzenie i zastosowanie pewnych procedur oraz wytycznych usprawniających przebieg i wyniki prac. Wprowadza też zbędną dezorganizację pracy. Uproszczony schemat postępowania w przypadku realizacji przeglądu dokumentacji projektowej przedstawia rysunek 2. W opisywanym procesie założono, iż dokumenty poddawane recenzji pochodzą z działu analizy a przeglądu dokonuje personel działu QA. Aby zapewnić zgodność z wymaganiami normy ISO, każdy proces (w tym opisywany tu przegląd) powinien mieć określone wejścia i wyjścia. Ta sama zasada dotyczy czynności wchodzących w skład danego procesu. Wejściem do procesu jest z reguły inny proces (poprzedzający), dokumenty, dane itp. Podobnie w przypadku wejść do poszczególnych czynności wynik (wyjście) poprzedniej czynności może być zarazem wejściem do następnej w kolejności. Analogicznie wyjściem z procesu może być inny proces (lub procesy, jeśli zachodzą równolegle lub warunkowo). W przypadku przeglądu dokumentacji wejściem będzie: proces analizy biznesowej (modelowania) lub / i projektowania, dokumentacja wymagań (np. rejestr wymagań klienta), 6

7 szablony dokumentów analitycznych, wymagania uzupełniające np. specyfikacje GUI etc. Wyjściem natomiast jest następny w kolejności element w głównym procesie wytwarzania oprogramowania: proces implementacji, zatwierdzona dokumentacja analityczna (lub ogólnie projektowa), opracowane raporty z przeglądu. Należy zidentyfikować również wszystkie wejścia, wyjścia i zależności pomiędzy poszczególnymi czynnościami wchodzącymi w skład procedury. Zasada jest prosta każde działanie powinno bazować na określonej informacji i produkować informację np. w oparciu o wytyczne karty kontrolnej oraz listę wymagań przeglądamy treść dokumentacji projektowej sprawdzając jej zgodność z ustalonymi założeniami. Wynikiem tego działania jest wypełniona karta kontrolna. Konieczność rejestrowania rezultatów wykonywanych czynności wynika z wymogów normy ISO 9001:2000 kładzie nacisk na utrzymywanie zapisów i nadzór nad dokumentami. Dostosowanie istniejących w firmie procesów do wymagań normy nie jest tak trudne, jakby się na pierwszy rzut oka wydawało. Czasem wystarczy jedynie poprawne udokumentowanie procesów i procedur, by zrealizować początkowe etapy wdrażania SZJ. Norma nie wymaga udokumentowania konkretnych procesów czy stworzenia określonych procedur ważne jest, aby przedsiębiorstwo zidentyfikowało kluczowe dla swojej misji procesy i ujęło je w systemie zarządzania jakością. Zakres systemu opisuje Księga jakości drugi co do ważności dokument zawierający politykę jakości oraz procedury (wykaz lub treść) i opisujący wdrożony w organizacji SZJ. Wynikiem procesu przeglądu mogą być niezgodności. Zgodnie z wytycznymi ISO każda niezgodność powinna zostać poddana analizie i rozwiązana (jeśli to tylko możliwe). Sposób postępowania z wykrytymi niezgodnościami opisuje dalsza część procedury. W zależności od potrzeb organizacji, wielkości i zakresu projektu informatycznego oraz ustalonego już procesu wytwarzania oprogramowania, można zastosować odmienne sposoby postępowania z wyrobem niezgodnym. Identyfikacja i komunikacja niezgodności może odbywać się w sposób mniej formalny, niż opisany w artykule, ważne jest jednak, aby zachować przy tym pewne ustalone zasady czynności muszą być powtarzalne i dawać konkretny, udokumentowany rezultat, wyniki czynności powinny 7

8 ISO 9001 w IT nadzór nad wyrobem niezgodnym być komunikowane zgodnie z planem komunikacji w przedsiębiorstwie oraz każda kwestia wymagająca podjęcia określonych działań musi pociągać za sobą realizację zadań przez odpowiedzialne za to osoby. Proces nadzoru nad produktem niezgodnym nie kończy się na dokumentacji w istocie jest to dopiero pierwsza część procesu mająca na celu jak najlepsze przygotowanie środowiska do produkcji kluczowego wyrobu systemu informatycznego. W dalszej kolejności należy zorganizować i sprawować nadzór nad niezgodnościami w fazie produkcji oprogramowania czyli implementacji i testowania. Jakość realizacji procesu nadzoru w tej fazie przekłada się bezpośrednio na jakość dostarczanego produktu i z tego powodu powinien stanowić jeden z kluczowych składników projektu informatycznego. Podsumowanie Norma ISO 9001 nie jest kolejnym elementem biurokracji. Pozwala usystematyzować procesy w przedsiębiorstwie, zapewnić ich wewnętrzną spójność i zgodność z podstawowymi standardami uznawanymi na całym świecie. Wdrożenie SZJ likwiduje chaos organizacyjny każdy pracownik zapoznaje się z założeniami systemu i wie, jakie sposoby postępowania i jakie zasady przyjąć wykonując swoją pracę. Odpowiedzialności są jasno określone dzięki czemu praktycznie wykluczają możliwość nieporozumień i manipulacji. Zastosowanie wspólnych szablonów dokumentacji usprawnia komunikację oraz efektywność pracy. Spełniając wymagania normy w zakresie nadzoru nad wyrobem niezgodnym, organizacja udoskonala swój proces wytwarzania oprogramowania oraz minimalizuje ryzyko błędów i dostarczenia klientowi produktu, który nie spełnia określonych wymagań. W przypadku przeglądu dokumentacji projektowej najbardziej istotną korzyścią jest możliwość wykrycia i uzupełnienia braków i niespójności w wymaganiach lub projekcie systemu. Nie od dziś wiadomo, iż im wcześniej wykryty błąd, tym mniejszy koszt jego naprawy i ryzyko propagacji w związku z czy poprawne wyniki fazy analizy i modelowania przekładają się na znaczący wzrost jakości produktu końcowego (systemu informatycznego) oraz samego procesu wytwarzania. Niniejszy artykuł przybliżył czytelnikowi pojęcie normy ISO 9001, jej postulatów i wymagań w kontekście rozwijania oprogramowania ze szczególnym uwzględnieniem punktu 8.3 dotyczącego nadzoru nad wyrobem niezgodnym. W części praktycznej dotyczącej wdrożenia wymagań normy ISO w organizacji IT przedstawiono przykładowe rozwiązanie dla procesu przeglądu dokumentacji projektowej, będącego pierwszym etapem nadzoru nad wyrobem niezgodnym podczas wytwarzania oprogramowania. Kolejne etapy procesu nadzoru w fazie implementacji i testowania oraz utrzymywania oprogramowania oraz ich przykładowe rozwiązanie zgodne z normą zostaną przedstawione w następnych częściach artykułu. KAROLINA ZMITROWICZ Pracuje na stanowisku Analityka biznesowego w rmie Pro Data. Karolina specjalizuje się obecnie w modelowaniu wymagań biznesowych. Wcześniej pracowała jako Manager Quality Assurance w projektach informatycznych w sektorze nansowo bankowym. Pro-Data to producent oprogramowania specjalizujący się w budowie dedykowanych rozwiązań informatycznych dla ubezpieczeń, bankowości i administracji publicznej. Firma posiada certykat jakości ISO9001:2000 w zakresie produkcji oprogramowania. Kontakt z autorem: karolina_zmitrowicz@wp.pl 8