Professional Documents
Culture Documents
ISO 9001 W IT - Nadzór Nad Wyrobem Niezgodnym W Procesie Produkcji Oprogramowania - Część I.
ISO 9001 W IT - Nadzór Nad Wyrobem Niezgodnym W Procesie Produkcji Oprogramowania - Część I.
ISO 9001 W IT - Nadzór Nad Wyrobem Niezgodnym W Procesie Produkcji Oprogramowania - Część I.
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
niezgodnym. W IT takim wyrobem jest system informatyczny oraz pozostae wytwory procesu produkcji oprogramowania.
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-
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.
W przypadku oceny Akceptacja warunkowa oraz Brak akceptacji pracownik QA wyszczeglnia punkty dokumentu, ktre naley poprawi lub uzupeni, aby uzyska akceptacj.
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).
36
05/2009