Narzdzia

ISO 9001 w IT
Nadzr nad wyrobem niezgodnym w procesie produkcji oprogramowania cz I.
Zgodnie z norm ISO 9001:2000 organizacja powinna sprawowa nadzr nad wyrobem niezgodnym. W IT takim wyrobem jest system informatyczny oraz pozostae wytwory procesu produkcji oprogramowania. Niniejszy artyku jest pierwszym z cyklu publikacji dotyczcych wdraania systemu zarzdzania jakoci w przemyle IT.
Jakie s wymagania normy ISO9001:2000 w zakresie nadzoru nad wyrobem niezgodnym; Co naley uwzgldni w procesie produkcji oprogramowania, by zapewni zgodno z norm; Dlaczego wdroenie systemu zarzdzania jakoci jest korzystne dla organizacji. Podstawowa wiedza z zakresu cyklu ycia oprogramowania; Znajomo poszczeglnych faz projektu IT oraz ich podstawowych celw i zaoe; Podstawowa wiedza z zakresu zarzdzania projektem informatycznym.

S to cechy istotne z punktu widzenia konsumenta. Producent musi oprcz tego bra pod uwag zyskowno i dziaalno konkurencji, co czsto jest w konflikcie z jakoci technologiczn produktu. Bardzo czsto zdarza si, i w trakcie produkcji wyrobu pojawiaj si rnego rodzaju niezgodnoci i odchylenia od projektowanej jakoci. Zgodnie z norm ISO 9001:2000 organizacja powinna sprawowa nadzr nad wyrobem

Poziom trudnoci

Jako oprogramowania:
oprogramowanie speniajce wymagania jakociowe odpowiada wymaganiom uytkownikw, jest niezawodne i atwe w utrzymaniu (Bell); cechy jakociowe produktu jakim jest oprogramowanie dotycz bezpieczestwa, moliwoci dostosowania, parametrw, funkcjonalnoci, niezawodnoci, oraz atwoci uytkowania (Morris); z punktu widzenia klienta i przechodzc na poziom oferty oprogramowania, poprzednio wymienione wasnoci powinny by rozszerzone o ograniczenia kosztw i terminw tak niskie, jak to tylko moliwe i zgodne z oczekiwaniami klientw (Arthur); jako z punktu widzenia programistw polega na zaprojektowaniu rozwiza programowych zgodnych z wymaganiami uytkownikw przy jednoczesnym dotrzymaniu terminw i kosztw opracowania. W tym przypadku jako opiera si na sprawnoci procesw opracowywania oprogramowania (Babey); jako w rozumieniu kierownika przedsibiorstwa dostarczajcego jest postrzegana w kategoriach terminw realizacji gotowego oprogramowania, poprawnoci procesu projektowania, braku reklamacji, itp. Charakterystyki jakoci opieraj si na zadowoleniu klientw oraz wynikaj z przebiegu procesu opracowywania (Marchal).

zym jest jako? Wedug najbardziej znanych definicji, jako to: zgodno z wymaganiami P.B. Cros-

by wszystko co mona poprawi Masaaki Imai og cech i waciwoci wyrobu lub usugi, ktre decyduj o zdolnoci wyrobu lub usugi do zaspokajania stwierdzonych i przewidywanych potrzeb ISO 8402 Norma ISO 9001:2000 okrela jako jako stopie, w jakim zbir inherentnych cech spenia wymagania. W tym kontekcie jako oznacza: zgodno ze specyfikacj i celem oraz zesp cech i charakterystyk wyrobu lub usugi, ktre nosz w sobie zdolno zaspokojenia okrelonych potrzeb. Do czsto jako postrzegana jest przez pryzmat jakoci technologicznej w aspektach funkcjonalnoci, praktycznoci, niezawodnoci, trwaoci oraz bezpieczestwa uytkowania. Z drugiej strony, jako moe by charakteryzowana wskanikami rynkowymi takimi jak: stopie zgodnoci z wzorcem lub zdefiniowanymi wymaganiami, widoczno zespou cech istotnych dla produktu, ekskluzywno, estetyczno, prezentacja, koszt nabycia bd usatysfakcjonowanie uytkownika, czyli zaspokojenie potrzeb i oczekiwa nabywcy.
34

ISO 9001:2000

Do gwnych wymaga normy ISO 9001 nale m.in.: wprowadzenie nadzoru nad dokumentacj i zapisami, zaangaowanie kierownictwa w budowanie systemu zarzdzania jakoci, usystematyzowanie zarzdzania zasobami, ustanowienie procesw realizacji wyrobu, dokonywanie systematycznych pomiarw (zadowolenia klienta, wyrobw, procesw) w tym nadzorowanie wyrobu niezgodnego z wymaganiami. Wymagania te uwzgldniaj osiem zasad jakoci: zorientowanie na klienta, przywdztw, zaangaowanie ludzi, podejcie procesowe, systemowe podejcie do zarzdzania, cige doskonalenie, rzeczowe podejcie do podejmowania decyzji, wzajemne korzyci w stosunkach z dostawcami.

05/2009

ISO 9001 w IT nadzr nad wyrobem niezgodnym

niezgodnym. W IT takim wyrobem jest system informatyczny oraz pozostae wytwory procesu produkcji oprogramowania.

Jako w produkcji oprogramowania

Gwnym wytworem przedsiwzicia informatycznego jest produkt system informa-

tyczny. Produkt informatyczny z racji swojego zrnicowania oraz wielu moliwych punktw widzenia moe by charakteryzowany rnymi definicjami jakoci (ramka nr 1). Rnorodno podej do problemu jakoci oprogramowania przejawia si w strukturze norm i standardw odnoszcych si do

przypadku oprogramowania dostarczonego (jako zewntrzna), do przypadku rezultatw projektowania (jako wewntrzna), do czynnoci opracowywania, do procesw opracowywania i do systemu jakoci. Jako postrzegana przez uytkownika oprogramowania dotyczy bezporednich wasnoci dostarczonego oprogramowania oraz usug to-

Przegld dokumentacji sposb postpowania

Przygotowanie dokumentacji projektowej
W terminie przewidzianym Planem Projektu Kierownik dziau analizy przygotowuje dokumentacj projektow do przegldu. Co najmniej 3 dni robocze przed upyniciem terminu oddania dokumentacji do przegldu, pracownicy Dziau Analizy dostarczaj Kierownikowi stworzone zgodnie z procedur Tworzenie dokumentacji projektowej skadniki dokumentacji, za ktrych stworzenie s odpowiedzialni, ze statusem Ukoczony. Lista wymaganych dokumentw projektowych wraz z wyszczeglnieniem osoby odpowiedzialnej (autora) oraz statusem jest przedstawiona w Licie dokumentacji. Kierownik dziau analizy odnotowuje przekazanie dokumentacji zmieniajc status odpowiednich pozycji na licie dokumentacji na Licie dokumentacji na Gotowy do przegldu. W terminie okrelonym Planem Projektu Kierownik dziau analizy przekazuje dokumentacj projektow Kierownikowi QA celem przegldu.

Przyjcie do przegldu

Kierownik QA przyjmuje dokumentacj projektow do przegldu i wystawia Kart odbioru. Karta odbioru musi zosta zatwierdzona przez Kierownika dziau analizy. Wystawiajc Kart odbioru Kierownik QA okrela: termin zakoczenia przegldu, osob odpowiedzialn za realizacj przegldu, stopie ryzyka

dla kadego dokumentu. Dokumenty opisane s nazw i typem. Okrelenie terminu zakoczenia przegldu odbywa si na podstawie Planu Projektu. Planujc przydzia zada pracownikom dziau QA Kierownik QA dokonuje podziau dokumentacji na bloki funkcjonalne. Jeden pracownik QA jest odpowiedzialny na wykonanie przegldu jednego bloku funkcjonalnego. Stopie ryzyka projektowego zwizanego z kadym dokumentem przyjmuje wartoci: Wysokie, rednie oraz Niskie. Termin zakoczenia przegldu jest ustalany w zalenoci od stopnia ryzyka dla dokumentu im wysze ryzyko, tym duszy czas przeznaczony na dokonanie przegldu. Kierownik QA przekazuje dokumenty do przegldu odpowiednim pracownikom EQA, zmieniajc status dokumentu na W przegldzie w Licie dokumentacji.

Przegld

Wyznaczony przez Kierownika QA pracownik przyjmuje dokument do przegldu i jest odpowiedzialny za jego wykonanie i przedstawienie wynikw przegldu przed upywem wyznaczonego w Karcie odbioru terminu. Przegld ma na celu kontrol zgodnoci z wymaganiami systemu zawartymi w Licie wymaga oraz spjnoci i kompletnoci dokumentacji projektowej. Elementy poddane przegldowi wyszczeglnia Karta kontrolna. Dokonujc przegldu, pracownik QA odnotowuje w Karcie wyniki. Niezwocznie po zakoczeniu przegldu pracownik QA sporzdza ogln ocen jakoci dokumentu projektowego w postaci dokumentu Akceptacji i przekazuje j wraz z wypenion Kart kontroln Kierownikowi. Ocena wyraana jest w skali trzystopniowej: Akceptacja, Akceptacja warunkowa, Brak akceptacji.

Opracowanie wynikw przegldu

W przypadku oceny Akceptacja warunkowa oraz Brak akceptacji pracownik QA wyszczeglnia punkty dokumentu, ktre naley poprawi lub uzupeni, aby uzyska akceptacj.

Opracowanie raportu kocowego

Kierownik QA odbiera Kart kontroln oraz Akceptacj od pracownika QA i zapoznaje si z ocen dokumentacji oraz z zawartoci Karty kontrolnej. Niezwocznie po otrzymaniu wynikw przegldu Kierownik QA sporzdza Raport z przegldu dokumentacji. Raport obejmuje: list dokumentw, dane pracownika wykonujcego przegld, status (Wstpna akceptacja lub Zwrcony do poprawy), uwagi (zawierajce uzasadnienie do statusu Zwrcony do poprawy).

Na podstawie protokow Akceptacji Kierownik okrela statusy dokumentw poddanych przegldowi. W przypadku Akceptacji warunkowej lub Braku akceptacji Kierownik zmienia status na Zwrcony do poprawy natomiast w przypadku Akceptacji na status: Wstpnie zaakceptowany. Zmieniajc status dokumentu na Zwrcony do naprawy Kierownik QA podaje uzasadnienie takiej decyzji. Tre uzasadnienia jest skrconym zapisem listy elementw wyznaczonych do poprawy lub uzupenienia, sporzdzonej w dokumencie Akceptacji. Po otrzymaniu wynikw przegldu od wszystkich pracownikw QA oraz aktualizacji statusw wszystkich dokumentw poddanych przegldowi, Kierownik QA przekazuje Raport z przegldu dokumentacji oraz Karty kontrolne Kierownikowi dziau analizy, ktry dokonuje formalnej akceptacji dokumentacji lub w przypadku wykazanych w dokumentach niezgodnoci przystpuje do etapu analizy niezgodnoci.

www.sdjournal.org

35

Narzdzia
warzyszcych zakupowi wynikajcych z umowy (pomoc techniczna, szkolenie, itp.). Normy standardy jakoci dziel si na grupy, zalenie od obszaru i procesu projektowania oprogramowania, ktrego dotycz (Rys. 1). Norma ISO obejmuje oglny system jakoci w przedsibiorstwie. Aby wymagania normy zostay spenione, konieczne jest usystematyzowanie i udokumentowanie okrelonych obszarw. Obszary te zostay przedstawione na schemacie podejcia procesowego (rys. 2).

Zarzdzanie produktem niezgodnym

Zgodnie z wymaganiami normy ISO 9001 proces wytwarzania wyrobu lub usugi powinien obejmowa sposb postpowania z produktem niezgodnym. Norma ISO 9001 mwi o tym w punkcie 8.3. Nadzr nad wyrobem niezgodnym (ramka). Zgodnie z powyszym punktem organizacja posiadajca wdroony System Zarzdzania Jakoci ISO 9001 powinna umie zidentyfikowa niezgodno produkowanego wyrobu z wymaganiami klienta i podj odpowiednie kroki w reakcji na zaistnia niezgodno. Dziaania te maj na celu wyeliminowa, lub zminimalizowa, ryzyko dostarczenia klientowi wyrobu, ktry nie spenia w peni okrelonych wymaga. W przypadku przedsibiorstwa zajmujcego si wytwarzaniem oprogramowania, nadzr nad produktem niezgodnym wystpuje na trzech etapach realizacji projektu informatycznego: w fazie analizy i projektowania, w fazie produkcji, po wdroeniu systemu na produkcj. Kady wymieniony etap projektu ma nieco inny cel. Inne s te produkty i w zwizku z tym naley stosowa odmienne metody i techniki nadzoru nad niezgodnociami. W pierwszej kolejnoci omwimy przykadowy proces nadzoru nad produktem niezgodnym na etapie analizy i projektowania systemu.

Rysunek 1. Normy i standardy jakoci

Wicej w papierowej wersji magazynu

Rysunek 2. Podejcie procesowe w normie ISO 9001

36

05/2009