Odpis normy ISO 9000-3

1 Przedmiot normy

Niniejszy arkusz normy ISO 9000 zawiera wytyczne ułatwiające organizacjom opracowującym, dostarczającym i obsługującym oprogramowanie stosowanie

normy ISO 9001.

Wytyczne przeznaczone są do stosowania, w przypadku gdy umowa między dwiema stronami wymaga wykazania zdolności dostawcy do opracowywania, dostarczania i obsługiwania wyrobów programowych.

Celem wytycznych zawartych w niniejszym arkuszu normy ISO 9000 jest określenie zalecanych sposobów zarządzania i metod produkcji oprogramowania spełniającego wymagania nabywcy. Mają one na celu głównie zapobieganie niezgodnościom na wszystkich etapach, od opracowania po obsługiwanie.

Wytyczne zawarte w niniejszym arkuszu normy ISO 9000 stosuje się w przypadku zawierania umów dotyczących oprogramowania, gdy:

a) umowa w szczególności wymaga prowadzenia prac projektowych oraz gdy wymagania dotyczące wyrobu są wyrażone głównie jako charakterystyki jego działania lub gdy istnieje konieczność ich usta

b) zaufanie do wyrobu może być osiągnięte, jeżeli dostawca w odpowiedni sposób wykaże swoje zdolności do opracowywania, dostarczania i obsługiwania.

2 Normy związane

Normy niżej wymienione zawierają postanowienia, które przez powołanie się na nie w niniejszym tekście, stają się postanowieniami tego arkusza normy ISO 9000. W momencie publikacji obowiązywały podane niżej edycje. Wszystkie normy podlegają nowelizacji i strony zawierające porozumienia na podstawie niniejszego arkusza normy ISO 9000 powinny szukać możliwości zastosowania najnowszych edycji niżej

wymienionych norm. Członkowie IEC i ISO posiadają rejestry aktualnie obowiązujących edycji norm międzynarodowych.

ISO 2382-1:1984, Przetwarzanie danych - Terminologia - 01: Podstawowe określenia.

ISO 8402:1986, Jakość - Terminologia.

ISO 9001:1987, Systemy jakości - Model zapewnienia

jakości w projektowaniu/ konstruowaniu, produkcji, instalowaniu i serwisie.

ISO 10011-1:1990, Wytyczne do auditowania systemów jakości - Arkusz 1: Auditowanie.

3 Definicje

Terminologia wg ISO 2382-1 i ISO 8402. W niniejszej części normy ISO 9000 przyjęto ponadto następujące definicje:

Odsyłacz krajowy: odpowiednik krajowy PN-88/

T-01016/01 Przetwarzanie informacji i komputery. Terminologia. Podstawowe terminy i definicje.

3.1 oprogramowanie:

Efekt pracy ludzkiego umysłu, obejmujący programy, procedury, zasady i wszelkie

dokumenty związane, dotyczące obsługiwania systemu przetwarzania danych. [ISO 2382-1:1984, 01.04.04]

UWAGA 4 Oprogramowanie jest niezależne od nośnika, na którym jest zapisane.

3.2 wyrób programowy:

Kompletny zestaw programów komputerowych, procedur i dokumentów związanych oraz danych, dostarczany użytkownikowi.

3.3 jednostka programowa:

Dowolna część wyrobu programowego identyfikowalna podczas pośredniego lub końcowego etapu opracowywania.

3.4 opracowywanie:

Ogół działań prowadzących do stworzenia wyrobu programowego.

3.5 etap:

Określony fragment pracy.

UWAGA 5 Etap nie wynika z zastosowania określonego modelu dotyczącego cyklu życiu, ani nie oznacza czasu w ramach procesu opracowywania wyrobu programowego.

3.6 weryfikacja (w odniesieniu do oprogramowania):

Proces oceny wyrobów danego etapu w celu zapewnienia prawidłowości i zgodności, w odniesieniu do wyrobów i norm dostarczonych jako dane wejściowe do tego etapu.

3.7 zatwierdzanie (w odniesieniu do oprogramowania):

Proces oceny oprogramowania w celu zapewnienia zgodności z określonymi wymaganiami.

4 System jakości - Struktura

4.1 Odpowiedzialność kierownictwa

4.1.1 Odpowiedzialność kierownictwa dostawcy

4.1.1.1 Polityka jakości

Kierownictwa dostawcy powinno określić i udokumentować swoją politykę, cele i zobowiązania dotyczące jakości. Dostawca powinien zapewnić, że polityka ta będzie zrozumiała oraz wprowadzana i utrzymywana na wszystkich szczeblach organizacji. [ISO 9001:1987, 4.1.1]

4.1.1.2 Organizacja

4.1.1.2.1 Odpowiedzialność i uprawnienia

Należy określić odpowiedzialność, uprawnienia i wzajemne zależności między personelem, który bierze udział w zarządzaniu, wykonuje i weryfikuje prace mające wpływ na jakość. Dotyczy to szczególnie tej części personelu, która potrzebuje swobody organizacyjnej i musi mieć odpowiednie uprawnienia, aby:

a) inicjować działania zapobiegające powstaniu nie zgodności wyrobu z wymaganiami;

b) identyfikować i zapisywać wszystkie problemy związane z jakością wyrobu;

c) inicjować, zalecać lub dostarczać rozwiązania problemów ustalonymi sposobami;

d) weryfikować wdrażanie rozwiązań;

e) nadzorować dalszą produkcję, dostawy 1ub instalowanie wyrobu niezgodnego z wymaganiami, do czasu gdy przyczyna niezgodności zostanie wykryta i usunięta. [ISO 9001:1987, 4.1.2.1]

4.1.1.2.2 Środki weryfikacji i personel weryfikujący

Dostawca powinien określić wewnętrzne wymagania weryfikacyjne, zapewnić odpowiednie środki i skierować wykwalifikowany personel do działań weryfikacyjnych.

Działania weryfikacyjne powinny obejmować: kontrolę, badania i monitorowanie procesów i/lub wyrobu w projektowaniu, produkcji, instalowaniu i serwisie. Przeglądy projektu i audity systemu jakości, procesów i/lub wyrobu powinny być przeprowadzane przez personel niezależny od bezpośrednio odpowiedzialnych za wykonywaną pracę. [ISO 9001:1987, 4.1.2:2]

4.1.1.2.3 Przedstawiciel kierownictwa

Dostawca powinien wyznaczyć przedstawiciela swego kierownictwa, który niezależnie od innych obowiązków, powinien mieć określone uprawnienia i odpowiedzialności w celu zapewnienia, że wymagania normy ISD 9001 są wprowadzane i przestrzegane. (ISO 9001:1987, 4.1.2.3]

4.1.1.3 Przegląd wykonywany przez kierownictwo

System jakości przyjęty w celu spełnienia wymagań normy ISO 9001 powinien być regularnie poddawany przeglądom przez kierownictwo dostawcy, aby zapewnić trwałą przydatność i efektywność tego systemu. Zapisy z przeglądów powinny być przechowywane.

UWAGA - Przeglądy wykonywane przez kierownictwo obejmują zazwyczaj ocenę wyników, wewnętrznych auditów jakości i są przeprowadzane przez kierownictwo dostawcy lub z jego upoważnienia przez personel kierowniczy bezpośrednio odpowiedzialny za system. [ISO 9001:1987, 4.1.3]

4.1.2 Odpowiedzialność kierownictwa nabywcy

Zaleca się, aby nabywca współpracował z dostawcą przez dostarczanie w porę niezbędnych informacji i uczestniczył w rozwiązywaniu pojawiających się

problemów. Zaleca się, aby nabywca wyznaczył swojego przedstawiciela, odpowiedzialnego za współpracę z dostawcą w zakresie spraw dotyczących umowy. Zaleca się, aby przedstawiciel ten posiadał uprawnienia współmierne do potrzeb wynikających z zajmowania się sprawami dotyczącymi umowy, które obejmują, nie wykluczając innych, następujące zagadnienia:

a) określanie wymagań nabywcy w stosunku do dostawcy;

b) odpowiadanie na pytania dostawcy;

c)zatwierdzanie propozycji dostawcy;

d) zawieranie porozumień z dostawcą;

e) zapewnienie, że organizacja przestrzega porozumień zawartych z dostawcą;

f)określanie procedur i kryteriów odbioru;

g) postępowanie z jednostkami programowymi dostarczonymi przez nabywcę, które okazały się nieprzydatne.

4.1.3 Wspólne przeglądy

Zaleca się zaplanowanie regularnych wspólnych przeglądów z udziałem dostawcy i nabywcy obejmujących, stosownie do potrzeb, następujące zagadnienia:

a) zgodność oprogramowania z uzgodnioną specyfikacją wymagań nabywcy;

b) wyniki weryfikacji;

c) wyniki badań odbiorczych;

Zaleca się, aby wyniki takich przeglądów były uzgodnione i udokumentowane.

4.2 System jakości

4.2.1 Postanowienia ogólne

Zaleca się, aby dostawca wprowadził i utrzymywał udokumentowany system jakości. Zaleca się, aby system jakości był zintegrowanym procesem obejmującym cały cykl życia, a zatem zapewniającym, że jakość jest budowana poprzez postęp osiągany na poszczególnych etapach, a nie odkrywana na końcu procesu.

Zaleca się położyć nacisk na działania zapobiegające powstawaniu problemów, a nie na działania korygujące podejmowane, wówczas gdy problemy te już wystąpią.

Zaleca się, aby dostawca zapewnił efektywne wdrożenie udokumentowanego systemu jakości.

4.2.2 Dokumentacja systemu jakości

Zaleca się, aby wszystkie elementy oraz wymagania i ustalenia dotyczące systemu jakości były w sposób systematyczny i uporządkowany wyrażanie udokumentowane.

4.2.3 Plan jakości

Zaleca się dostawcy przygotować i udokumentować plan jakości w celu wdrożenia działania dotyczącego jakości dla każdego procesu opracowywania oprogramowania, na podstawie systemu jakości oraz zapewnić, że jest on rozumiany i przestrzegany w organizacjach, których dotyczy.

4.3 Wewnętrzne audity systemu jakości

Wewnętrzne audity jakości

Dostawca powinien opracować i stosować system zaplanowanych i udokumentowanych wewnętrznych auditów jakości w celu zweryfikowania, czy działania w zakresie jakości są zgodne z zaplanowanymi oraz w celu określenia efektywności systemu jakości.

Audity powinny być planowane odpowiednio do sytuacji oraz ważności działań. Audity i wynikające z nich działania powinny być prowadzone zgodnie z udokumentowanymi procedurami.

Wyniki auditów powinny być dokumentowane i przekazywane do wiadomości personelowi odpowiedzialnemu za audirowany obszar działań. Kadra kierownicza, odpowiedzialna za dany obszar działań, powinna podejmować okresowo działania korygujące nieprawidłowości ujawnione w wyniku auditu. [ISO 9001:1987, 4.17] Patrz ISO 10011

4.4 Działania korygujące

Dostawca powinien wprowadzić, udokumentować i przestrzegać następujących procedur:

a) badania przyczyn niezgodności wyrobu oraz prowadzenia działań korygujących, zapobiegającyc5 powtarzaniu się niezgodności;

b) analizowania wszystkich procesów, operacji roboczych, odstępstw, zapisów dotyczących jakości, raportów dotyczących obsługi oraz reklamacji odbiorcy w celu wykrycia i wyeliminowania potencjalnych przyczyn niespełnienia wymagań przez wyrób;

c) inicjowania działań zapobiegawczych mających na celu rozwiązanie problemów, tak aby nie przekroczyć poziomu oszacowanego ryzyka; d) stosowania środków nadzoru zapewniających skuteczność podejmowanych działań korygujących;

d) stosowania środków nadzoru zapewniających skuteczność podejmowania działań korygujących

e) wdrażania i zapisywania, wynikających z działań korygujących, zmian w procedurach.[ISO 9001:1987, 4.14]

5 System jakości - Działania dotyczące cyklu życia

5.1 Postanowienia ogólne

Zaleca się, aby przedsięwzięcie związane z opracowywaniem oprogramowania było zorganizowane zgodnie z modelem cyklu życia oprogramowania. Zaleca się, aby działania dotyczące jakości były zaplanowane i wdrożone z uwzględnieniem charakteru stosowanego modelu.

Niniejsza część ISO 9000 jest przeznaczona do stosowania bez względu na przyjęty model cyklu tycia. Jeśli jakiś opis, wytyczna, wymaganie lub struktura może

być zrozumiana w różny sposób, nie jest to intencją normy i nie zaleca się, by rozumiano to jako wskazanie, że dane wymaganie lub wytyczna ograniczają się

do jednego, ściśle określonego modelu cyklu życia.

5.2 Przegląd umowy

5.2.1 Postanowienia ogólne

Zaleca się, aby dostawca wprowadził i przestrzegał procedur przeglądu umowy i koordynacji związanych z tym działań.

Zaleca się, aby dostawca dokonał przeglądu każdej umowy w celu zapewnienia, że:

a) zakres umowy i wymagania są określone i udokumentowane;

b) ewentualne nieprzewidziane okoliczności i ryzyko są znane;

c) informacje dotyczące praw własności są odpowiednio zabezpieczone;

d) sprawy wszelkich wymagań różniących się od zawartych w ofercie są rozwiązane;

e) dostawca jest zdolny do spełnienia wymagań zawartych w umowie;

f) określona jest odpowiedzialność dostawcy w odniesieniu do prac wykonanych przez podwykonawców;

g) terminologia jest uzgodniona przez obie strony;

h) nabywca jest zdolny do spełnienia zobowiązań wynikających z umowy.

Zaleca się, aby zapisy dotyczące przeglądów umów były przechowywane.

5.2.2 Pozycje umowy dotyczące jakości

Umowa często obejmuje, między innymi, następujące pozycje:

a) kryteria odbioru;

b) postępowanie w przypadku wprowadzania przez nabywcę zmian do wymagań w trakcie opracowywania;

c) rozwiązywanie problemów wykrytych po odbiorze, włącznie z reklamacjami dotyczącymi jakości oraz skargami nabywcy;

d) działania podejmowane przez nabywcę, zwłaszcza określenie roli nabywcy podczas tworzenia specyfikacji wymagań, instalowania i odbioru;

e) oprzyrządowanie, narzędzia i jednostki programowe dostarczane przez nabywcę;

stosowane normy i procedury;

g) wymagania dotyczące kopiowania.

5.3 Specyfikacja wymagań nabywcy

5.3.1 Postanowienia ogólne

Zaleca się, aby przed przystąpieniem do opracowywania oprogramowania, dostawca posiadał kompletny i jednoznaczny zestaw wymagań funkcjonalnych. Dodatkowo, zaleca się, aby wymagania te obejmowały wszelkie zagadnienia konieczne do zaspokojenia potrzeb nabywcy. Zagadnienia to mogą dotyczyć (nie wykluczając innych): wykonania, bezpieczeństwa, niezawodności, zabezpieczenia oprogramowania i utrzymania poufności. Zaleca się, aby wymagania te były określone wystarczająco dokładnie, by umożliwić zatwierdzenie podczas odbioru wyrobu.

Specyfikacja wymagań nabywcy jest zapisem tych wymagań. W niektórych przypadkach dokument ten jest opracowywany i dostarczany przez nabywcę. Jeśli nie, to zaleca się, aby dostawca opracował takie wymagania w ścisłej współpracy z nabywcą oraz uzyskał ich zatwierdzenie przez nabywcę przed przystąpieniem do działania. Zaleca się, aby specyfikacja wymagań nabywcy była przedmiotem nadzoru nad dokumentacją oraz zarządzania konfiguracją, jako część dokumentacji dotyczącej realizowanego procesu.

Zaleca się, aby wszystkie interfejsy pomiędzy wyrobem programowym a innymi wyrobami programowymi i sprzętem były w pełni określone, bezpośrednio

lub przez przywołanie, w specyfikacji wymagań nabywcy.

5.3.2 Wzajemna współpraca

Podczas opracowywania specyfikacji wymagań nabywcy zaleca się zwrócenie uwagi na następujące kwestie:

a) wyznaczenie osób (po obu stronach) odpowiedzialnych za ustalenie specyfikacji wymagań nabywcy; metody uzgadniania wymagań i zatwierdzania zmian; działania zapobiegające powstawaniu nieporozumień, takie jak zdefiniowanie terminologii, uzasadnienie poszczególnych wymagań; sporządzanie i poddawanie przeglądom, przez obie strony, zapisów dotyczących wyników dyskusji.

5.4 Planowanie opracowywania

5.4.1 Postanowienia ogólne

Zaleca się, aby plan opracowywania obejmował:

a) zdefiniowanie przedsięwzięcia, włącznie z określeniem celów i przywołaniem przedsięwzięć związanych nabywcy lub dostawcy;

b) organizację środków do przedsięwzięcia, włącznie ze strukturą zespola, podziałem odpowiedzialności, korzystaniem z podwykonawstwa oraz zasobów materiałowych;

c) etapy opracowywania (określone jak w 5.4.2.1);

d) plan przedsięwzięcia określający zadania, środki i czas wymagane dla każdego zadania oraz relacje pomiędzy poszczególnymi zadaniami;

e) identyfikację planów związanych, takich jak:

- plan jakości,

- plan zarządzania konfiguracją,

- plan integracji,

- plan badań.

Zaleca się, aby plan opracowywania był aktualizowany w miarę postępu prac, a każdy etap był określony, jak w 5.4.2.1, przed podjęciem działań z nim związanych. Zaleca się, aby był on poddany przeglądowi i zatwierdzony przed rozpoczęciem realizacji.

 

5.4.2 Plan opracowywania

5.4.2.1 Etapy

Zaleca się, aby plan opracowywania określał precyzyjnie opisany proces lub metodologię przekształcania specyfikacji wymagań nabywcy w wyrób programowy.

Może to wymagać podziału całości prac na etapy oraz określenia:

a) poszczególnych etapów opracowywania;

b) wymagań dotyczących danych wejściowych dla każdego etapu;

c) wymagań dotyczących danych wyjściowych z każdego etapu;

d) procedur weryfikacyjnych dla każdego etapu;

e) analiz potencjalnych problemów związanych z po-szczególnymi etapami opracowywania i ze spełnieniem określonych wymagań.

5.4.2.2 Zarządzanie

Zaleca się, aby plan opracowywania określał zasady zarządzania przedsięwzięciem i obejmował:

a) harmonogram opracowywania, wdrażania i związanych z tym dostaw;

b) nadzorowanie postępu prac;

c) organizacyjny podział odpowiedzialności, środków i zadań;

d) organizacyjne i techniczne powiązania pomiędzy różnymi grupami.

5.4.2.3 Metody i narzędzia stosowane podczas opracowywania

Zaleca się, aby plan opracowywania określał metody zapewniające, że wszystkie czynności wykonywane są właściwie. Może to obejmować:

a) zasady, praktyki i reguły opracowywania;

b) narzędzia i techniki opracowywania;

c) zarządzanie konfiguracją.

5.4.3 Nadzorowanie postępu prac

Zaleca się, aby przeglądy postępu prac były planowane, przeprowadzane i dokumentowane w celu zapewnienia, że nie załatwione problemy dotyczące środków zostały rozwiązane oraz zapewnienia skutecznej realizacji planów opracowywania.

5.4.4 Dane wejściowe do etapów opracowywania

Zaleca się, aby dane wejściowe wymagane do każdego etapu były określone i udokumentowane. Zaleca się takie sformułowanie każdego wymagania, aby jego spełnienie mogło być zweryfikowane. Zaleca się, aby sprawy wymagań niekompletnych, niejednoznacznych lub sprzecznych były rozwiązane przez osoby odpowiedzialne za ich sformułowanie.

5.4.5 Dane wyjściowe z etapów opracowywania

Zaleca się, aby dane wyjściowe wymagane po każdym etapie były określone i udokumentowane. Zaleca się, aby dane wyjściowe z każdego etapu były weryfikowane, a także:

a) spełniały odpowiednie wymagania;

b) obejmowały lub przywoływały kryteria odbioru, których spełnienie warunkuje przejście do kolejnych etapów;

c) były zgodne z odpowiednimi praktykami i regułami, bez względu na to, czy były one przywołane w danych wejściowych, czy też nie;

d) określały te właściwości wyrobu, które decydują o jego bezpiecznym i właściwym funkcjonowaniu;

e) były zgodne ze stosowanymi przepisami.

5.4.6 Weryfikacja każdego etapu

Zaleca się, aby dostawca sformułował plan weryfikacji danych wyjściowych ze wszystkich etapów opracowywania, po ich zakończeniu. Zaleca się, aby w wyniku weryfikacji opracowywania ustalono, czy dane wyjściowe z danego etapu spełniają odpowiednie wymagania wynikające z danych wejściowych, za pomocą takich środków sterowania opracowywaniem, jak:

a) przeprowadzanie przeglądów w odpowiednich momentach poszczególnych etapów;

b) porównywanie nowego projektu z podobnym, sprawdzonym projektem, jeżeli jest to możliwe;

c) przeprowadzanie badań i prezentacji.

Zaleca się, aby wyniki weryfikacji i wszelkie dalsze działania wymagane do zapewnienia, że określone wymagania są spełnione, były zapisywane i sprawdzane po zakończeniu tych działań. Zaleca się, aby tylko zweryfikowane dane wyjściowe były przedstawiane zarządzającym konfiguracją i zatwierdzane do dalszego

stosowania.

 

5.5 Planowanie jakości

5.5.1 Postanowienia ogólne

Zaleca się, aby dostawca przygotował plan jakości, w ramach planowania opracowywania. Zaleca się, aby plan jakości był uaktualniany równolegle z postępem opracowywania, a pozycje dotyczące każdego etapu były w sposób pełny zdefiniowane przed jego rozpoczęciem.

Zaleca się, aby plan jakości był poddawany formalnym przeglądom i uzgadniany przez wszystkie organizacje, które uczestniczą w jego realizacji.

Dokument opisujący plan jakości (patrz 5.5.2) może być dokumentem niezależnym (zatytułowanym "plan jakości"), częścią innego dokumentu lub zbiorem kilku dokumentów, z planem opracowywania włącznie.

5.5.2 Zawartość planu jakości

Zaleca się, aby plan jakości zawierał lub przywoływał następujące pozycje:

a) cele jakościowe, wyrażone, jeśli to możliwe, w sposób wymierny;

b) określone kryteria dotyczące danych wejściowych i wyjściowych dla każdego etapu opracowywania;

c) określenie rodzajów badań, które będą stosowane a także weryfikacji i sposobu zatwierdzania;

d) szczegółowe plany przewidzianych działań związanych z badaniami, weryfikacją i zatwierdzaniem, także określenie harmonogramów, środków i osób uprawnionych do ich zatwierdzania;

e) określenie odpowiedzialności za działania związane z jakością, takie jak:

- przeglądy i badania;

- zarządzanie konfiguracją i nadzór nad zmianami;

- postępowanie z wyrobami nie spełniającymi wymagań oraz działania korygujące.

5.6 Projektowanie i wdrażanie

5.6.1 Postanowienia ogólne

Działania dotyczące projektowania i wdrażania polegają na przekształceniu specyfikacji wymagań nabywcy w wyrób programowy. Ze względu na złożony charakter wyrobów programowych jest konieczne, aby działania te były przeprowadzone w sposób precyzyjny w celu osiągnięcia zgodności wyrobu ze specyfikacją, a nie tylko na podstawie wyników badań i procesu zatwierdzania - dotyczących zapewnienia jakości.

UWAGA 6 Zaleca się, aby zakres informacji dostarczanych nabywcy był uzgodniony przez obie strony, ponieważ procesy projektowania i wdrażania są często objęte prawem własności dostawcy.

5.6.2 Projektowanie

Zaleca się, aby oprócz wymagań wspólnych dla wszystkich etapów opracowywania wzięto pod uwagę następujące zagadnienia nieodłącznie związane z projektowaniem:

a) Określenie uwarunkowań dotyczących projektowania: zaleca się, aby oprócz specyfikacji danych wejściowych i wyjściowych sprawdzeniu podlegały takie zagadnienia, jak zasady projektowania i określania wewnętrznych interfejsów.

b) Metodologia projektowania: zaleca się stosowanie systematycznej metodologii projektowania, odpowiedniej do rodzaju opracowywanego wyrobu programowego.

c) Wykorzystanie doświadczeń projektowych: zaleca się, aby dostawca wykorzystując doświadczenia wynikające z dotychczas prowadzonych prac projektowych, starał się unikać ponownego rozwiązywania takich samych lub podobnych problemów.

d) Kolejne procesy: zaleca się, aby projektowanie obejmowało zakres zagadnień, które ułatwią późniejsze badania, obsługiwanie i użytkowanie.

5.6.3 Wdrażanie

Oprócz wymagań wspólnych dla wszystkich etapów opracowywania zaleca się uwzględnienie następujących elementów wdrażania:

a) Zasady: zaleca się, aby takie zasady, jak: zasady programowania, języki programowania, konsekwentnie stosowane nazewnictwo, kodowanie i odpowiednie zasady dotyczące stosowania komentarzy były określone i przestrzegane.

b) Metodologie wdrażania: zaleca się, aby dostawca stosował odpowiednie metody i środki podczas procesu wdrażania w celu spełnienia wymagań nabywcy.

5.6.4 Przeglądy

Zaleca się, aby dostawca przeprowadzał przeglądy w celu zapewnienia, że wymagania są spełnione, a powyższe metody stosowane są we właściwy sposób. Nie zaleca się, aby proces projektowania i wdrażania był kontynuowany, dopóki wszystkie wykryte nieprawidłowości nie zostaną usunięte lub będzie znane ryzyko

kontynuowania.

Zaleca się przechowywanie zapisów dotyczących takich przeglądów.

5.7 Badania i zatwierdzanie

5.7.1 Postanowienia ogólne

Badania mogą być wymagane na różnych poziomach; od pojedynczej jednostki programowej do kompletne go wyrobu programowego. Znane są różne możliwości prowadzenia badań i integracji.

W niektórych przypadkach proces zatwierdzania, badania eksploatacyjne i badania odbiorcze mogą być przeprowadzane jako jedno, wspólne działanie.

Dokument zawierający opis planu badań może być dokumentem niezależnym, być częścią innego dokumentu lub stanowić zbiór kilku dokumentów.

5.7.2 Planowanie badań

Zaleca się, aby dostawca opracował i dokonał przeglądu planów badań, specyfikacji i procedur przed rozpoczęciem badań, zwracając uwagę na:

a) plany badań dotyczących pojedynczych jednostek programowych, ich integracji, całych systemów oraz plany badań odbiorczych;

b) przypadki prowadzenia badań, dane dotyczące tych badań oraz spodziewane wyniki;

c) rodzaje prowadzonych badań, np.: badania funkcjonalności, badania w warunkach krytycznych, badania wykonania, badania przydatności do użytku;

d) warunki otoczenia podczas badań, narzędzia i oprogramowanie badawcze;

e) kryteria, według których będzie oceniana realizacja programu badań;

f) dokumentację dla użytkownika;

g) wymagania dotyczące personelu i związanego z tym szkolenia.

5.7.3 Badania

Zaleca się, aby specjalną uwagę poświęcono następującym zagadnieniom dotyczącym badań:

a) zapisywaniu wyników badań w sposób określony w odpowiedniej specyfikacji;

b) zapisywaniu wszystkich wykrytych problemów i ich ewentualnego wpływu na inne części oprogramowania oraz powiadamianiu osób odpowiedzialnych, aby problemy te mogły być śledzone, aż do momentu ich rozwiązania;

c) określaniu i poddaniu ponownym badaniom obszarów, na które miały wpływ przeprowadzone modyfikacje;

d) ocenianiu czy prowadzone badania są odpowiednie i wystarczające;

e) rozważeniu i udokumentowaniu konfiguracji sprzętu i oprogramowania.

5.7.4 Zatwierdzanie

Zaleca się, aby przed przedstawieniem wyrobu do odbioru i jego przyjęciem przez nabywcę, dostawca zatwierdził całość jego działania jako kompletnego wyrobu, jeśli to możliwe - w warunkach zbliżonych do środowiska określonego w umowie.

5.7.5 Badania eksploatacyjne

Zaleca się, aby w przypadku, gdy wymagane są badania eksploatacyjne zwrócono uwagę na:

a) cechy, które mają być badane w środowisku eksploatacji;

b) podział odpowiedzialności pomiędzy dostawcą a nabywcą za przeprowadzenie i ocenę badań;

c) rekonstrukcję środowiska użytkownika (po przeprowadzeniu badań).

5.8 Odbiór

5.8.1 Postanowienia ogólne

Kiedy dostawca jest gotowy do dostarczenia zatwierdzonego wyrobu, zaleca się, aby nabywca ocenił czy wyrób spełnia uzgodnione wcześniej kryteria w sposób określony w umowie.

Zaleca się, aby metoda postępowania w przypadku wykrycia problemów w ramach procedury odbioru i dyspozycje z tym związane były uzgodnione pomiędzy nabywcą a dostawcą oraz udokumentowane.

5.8.2 Planowanie badań

Zaleca się, aby przed podjęciem działań związanych z odbiorem dostawca pomógł nabywcy w ustalaniu:

a) harmonogramu;

b) procedur oceny;

c) środków i środowiska programowego i sprzętowego;

d) kryteriów odbioru.

5.9 Kopiowanie, dostarczanie i instalowanie

5.9.1 Kopiowanie

Kopiowanie jest działaniem, które zaleca się przeprowadzić przed dostarczeniem. Przy sporządzaniu ustaleń dotyczących kopiowania należy wziąć pod uwagę:

a) liczbę kopii każdej jednostki programowej, która ma być dostarczona;

b) rodzaj nośnika dla każdej jednostki programowej, włącznie z określeniem formatu i wersji, w formie czytelnej dla człowieka;

c) zastrzeżenia dotyczące wymaganej dokumentacji, takiej jak instrukcja obsługi i wytyczne dla użytkownika;

d) uzgodnienia dotyczące praw autorskich i licencji;

e) ochronę kopii głównych i dodatkowych, jeśli to właściwe, włącznie z planami dotyczącymi odtworzenia w przypadku zniszczenia kopii;

f) termin, w którym dostawca jest zobowiązany do dostarczenia kopii.

5.9.2 Dostarczanie

Zaleca się, aby przyjęte zostały ustalenia dotyczące weryfikacji prawidłowości i kompletności kopii dostarczanego wyrobu programowego.

5.9.3 Instalowanie

Zaleca się, aby podział zadań, odpowiedzialności i zobowiązań dostawcy i nabywcy był jasno określony i uwzględniał:

a) harmonogram, uwzględniający pracę w nadgodzinach i w dni wolne od pracy;

b) zasady wstępu do pomieszczeń nabywcy (przepustki, hasła, eskorta);

c) możliwości korzystania z usług wykwalifikowanego personelu;

d) dostęp i możliwości korzystania z systemów i wyposażenia nabywcy;

e) konieczność zatwierdzania, jako część każdego procesu instalowania, którą zaleca się określić w umowie;

f) formalną procedurę przyjęcia każdego procesu instalowania po jego zakończeniu.

5.10 Obsługiwanie

5.10.1 Postanowienia ogólne

Zaleca się, aby w przypadku wymagania przez nabywcę dalszego obsługiwania wyrobu programowego - po zakończeniu dostaw i procesu instalowania - było to zastrzeżone w umowie. Zaleca się, aby dostawca opracował i utrzymywał procedury, dotyczące obsługiwania oraz weryfikowania, czy obstugiwanie to

spełnia określone wymagania.

Obsługiwanie wyrobu programowego dotyczy głównie:

a) rozwiązywania problemów;

b) modyfikacji interfejsów;

c) rozszerzania obszaru działania i wprowadzania ulepszeń.

Zaleca się, aby pozycje, które mają być objęte obsługiwaniem oraz okres obsługiwania były określone w umowie. Przykłady takich pozycji to:

a) program(-y);

b) zbiory danych i ich struktury;

c) specyfikacje;

d) dokumenty dla nabywcy i/lub użytkownika;

e) dokumenty do użytku dostawcy.

5.10.2 Plan obsługiwania

Zaleca się, aby wszystkie działania związane z obsługiwaniem były prowadzone i zarządzane zgodnie z planem obsługiwania, wcześniej opracowanym i uzgodnionym pomiędzy dostawcą a nabywcą. Zaleca się, aby plan zawierał:

a) zakres obsługiwania;

b) określenie wstępnego statusu wyrobu;

c) organizacja(-e) wspierająca(-e);

d) działania związane z obsługiwaniem;

e) zapisy i raporty dotyczące obsługiwania.

5.10.3 Określenie wstępnego statusu wyrobu

Zaleca się, aby wstępny status obsługiwanego wyrobu był określony, udokumentowany i uzgodniony pomiędzy dostawcą a nabywcą.

5.10.4 Organizacja wspierająca

Może się okazać konieczne powołanie organizacji z przedstawicielami dostawcy i nabywcy w celu wspierania działań związanych z obsługiwaniem. Ponieważ działania związane z obsługiwaniem nie zawsze mogą być prowadzone ściśle według przygotowanych harmonogramów, zaleca się, aby organizacja ta była wystarczająco elastyczna, by w przypadku wystąpienia nieprzewidzianych problemów podjąć stosowne działania. Konieczne może być też określenie odpowiednich warunków i środków do prowadzenia działań dotyczących obsługiwania.

5.10.5 Rodzaje obsługiwania

Zaleca się, aby wszystkie zmiany wprowadzane do oprogramowania (w celu rozwiązania problemu, modyfikacji interfejsów, rozszerzenia obszaru działania lub wprowadzenia ulepszeń) w trakcie obsługiwania były dokonywane, tak dalece, jak to możliwe, zgodnie z procedurami, które były stosowane podczas opracowywania wyrobu programowego. Zaleca się, aby wszystkie takie zmiany były także dokumentowane zgodnie z procedurami dotyczącymi nadzoru nad dokumentacją i zarządzania konfiguracją.

a) Rozwiązywanie problemu: rozwiązywanie problemu obejmuje wykrycie, analizę i poprawienie niezgodności w oprogramowaniu powodujących występowanie problemów operacyjnych. Gdy problemy zostaną rozwiązane, można zastosować tymczasowe działania naprawcze w celu zminimalizowania czasu przestoju, a trwałą modyfikację wprowadzić w terminie późniejszym.

b) Modyfikacje interfejsów: modyfikacje interfejsów mogą być wymagane, jeżeli w systemie sprzętowym lub jego elementach sterowanych programowo nastąpiły zmiany.

c) Rozszerzenie obszaru działania lub wprowadzanie ulepszeń: nabywca może wymagać, aby w zakresie istniejących funkcji obsługiwanie obejmowało rozszerzenie obszaru działania lub wprowadzanie ulepszeń.

5.10.6 Zapisy i raporty dotyczące obsługiwania

Zaleca się sporządzanie i przechowywanie zapisów dotyczących wszystkich działań związanych z obsługiwaniem we wcześniej ustalonej formie. Zaleca się, aby pomiędzy dostawcą a nabywcą były ustalone i uzgodnione zasady przedkładania raportów dotyczących obsługiwania.

Zaleca się, aby dla każdej jednostki programowej objętej obsługiwaniem, zapisy dotyczące obsługiwania zawierały:

a) listę otrzymywanych wystąpień o udzielenie pomocy lub raportów dotyczących poszczególnych problemów oraz ich aktualny status;

b) organizację odpowiedzialną za reagowanie na wystąpienia o udzielenie pomocy lub podejmowanie odpowiednich działań korygujących;

c) określenie priorytetów w zakresie działań korygujących;

d) wyniki działań korygujących;

e) dane statystyczne dotyczące występujących problemów i działań związanych z obsługiwaniem. Zapisy dotyczące obsługiwania mogą być wykorzystane do oceny i doskonalenia wyrobu programowego jak i do stałego doskonalenia samego systemu jakości

5.10.7 Procedury dotyczące wprowadzenia wersji wyrobu

Zaleca się, aby dostawca i nabywca uzgodnili i udokumentowali procedury wprowadzenia do wyrobu programowego zmian wynikających z potrzeby utrzymania założonego poziomu wykonania.

Zaleca się, aby procedury te zawierały:

a) podstawowe zasady określające gdzie "wstawki' mogą być wprowadzone lub gdzie jest potrzebni wydanie kompletnej, zaktualizowanej kopii wyrobu programowego;

b) opis typów (lub kategorii) wersji w zależności od ich częstości i/tub wpływu na operacje prowadzono przez nabywcę oraz możliwości wprowadzania zmian w każdym momencie;

c) metody powiadamiania nabywcy o bieżących i planowanych zmianach;

d) metody potwierdzania, że wprowadzone zmian nie spowodują pojawienia się innych problemów;

e) wymagania dotyczące wykazywania w zapisach gdzie i jakie zmiany zostały wprowadzone w odniesieniu do różnych wyrobów znajdujących się w różnych miejscach.

 

6 System jakości - Działania wspomagające

(niezależne od etapu)

6.1 Zarządzanie konfiguracją

6.1.1 Postanowienia ogólne

Zarządzanie konfiguracją stanowi mechanizm do identyfikowania, nadzorowania i śledzenia różnych wersji każdej jednostki programowej. W wielu przypadkach wersje wcześniejsze, które są w dalszym ciągu stosowane, muszą być także obsługiwane i nadzorowane.

Zaleca się, aby system zarządzania konfiguracją:

a) identy6kował w niepowtarzalny sposób poszczególne wersje każdej jednostki programowej;

b) identyfikował wersje każdej jednostki programowej, które wspólnie stanowią określoną wersję kompletnego wyrobu;

c) identyfikował status wyrobów programowych w trakcie ich opracowywania lub dostarczanych i instalowanych;

d) kontrolował równoczesne uaktualnianie danej jednostki programowej przez więcej niż jedną osoby;

e) zapewniał koordynację uaktualniania różnych wyrobów w jednym lub kilku miejscach, jeśli jest to wymagane;

f) identyfikował i śledził wszystkie działania i zmiany wynikające ze zmian zapotrzebowania, od etapu początkowego, aż do wydania kolejnej wersji.

6.1.2 Plan zarządzania konfiguracją

Zaleca się, aby dostawca opracował i wprowadził plan zarządzania konfiguracją, obejmujący:

a) organizacje uczestniczące w zarządzaniu konfiguracją i podział odpowiedzialności między nimi;

b) działania związane z zarządzaniem konfiguracją, które należy przeprowadzić;

c) narzędzia, techniki i metodologie dotyczące zarządzania konfiguracją, które należy zastosować;

d) określenie etapu, od którego poszczególne pozycje zaleca się objąć nadzorem nad konfiguracją.

6.1.3 Działania dotyczące zarządzania konfiguracją

6.1.3.1 Oznaczanie i identyfikowalność konfiguracji

Zaleca się, aby dostawca ustanowił i utrzymywał procedury oznaczania jednostek programowych podczas wszystkich etapów, poczynając od specyfikacji, przez opracowywanie, kopiowanie i dostarczanie. Tam, gdzie jest to wymagane umową, procedury te mogą także obejmować działania podejmowane po dostarczeniu wyrobu. Zaleca się, aby każda pojedyncza jednostka programowa była oznaczona w niepowtarzalny sposób.

Zaleca się stosowanie procedury w celu zapewnienia, te dla każdej wersji danej jednostki programowej możliwa jest identyfikacja:

a) specyfikacji technicznych i funkcjonalnych;

b) sprzętu stosowanego podczas opracowywania, który ma wpływ na specyfikacje funkcjonalne i techniczne;

c) wszystkich interfejsów z innymi jednostkami programowymi i ze sprzętem;

d) wszystkich dokumentów i plików komputerowych odnoszących się do danej jednostki programowej.

Zaleca się, aby sposób identyfikacji jednostki programowej umożliwiał pokazanie powiązań pomiędzy daną jednostką programową a wymaganiami umowy. Zaleca się, aby dla wyrobów wydanych zostały opracowane procedury umożliwiające identyfikowalność jednostki programowej lub wyrobu programowego.

6.1.3.2 Nadzór nad zmianami

Zaleca się, aby dostawca wprowadził i przestrzegał procedur określania, dokumentowania, przeglądu i zatwierdzania wszelkich zmian w jednostkach programowych objętych zarządzaniem konfiguracją. Zaleca się, aby wszelkie zmiany w jednostkach programowych były przeprowadzane zgodnie z tymi procedurami.

Zaleca się, aby przed przyjęciem zmiany była potwierdzona jej zasadność, a jej wpływ na inne jednostki był określony i sprawdzony.

Zaleca się ustalenie metody powiadamiania o zmianach tych osób, których zmiany dotyczą oraz ustalenie sposobów wykazywania identyfikowalności pomiędzy zmianami i modyfikowanymi częściami jednostek programowych.

6.1.3.3 Informowanie o statusie konfiguracji

Zaleca się, aby dostawca wprowadził i przestrzegał procedur sporządzania zapisów, zarządzania i informowania o statusie jednostki programowej, zgłaszanych potrzebach dotyczących wprowadzenia zmian i wprowadzania zatwierdzonych zmian.

6.2 Nadzór nad dokumentacją

6.2.1 Postanowienia ogólne

Zaleca się, aby dostawca wprowadził procedury nadzoru nad całą dokumentacją dotyczącą zawartości niniejszej części normy ISO 9000 i przestrzegał ich. Obejmuje to:

a) określenie dokumentów, które zaleca się objąć procedurami nadzoru nad dokumentacją;b) zatwierdzanie i wydawanie procedur;c) procedury wprowadzania zmian, włącznie z wycofywaniem i, jeśli to właściwe, wprowadzeniem kolejnej wersji.

6.2.2 Rodzaje dokumentów

Zaleca się, aby procedury nadzoru nad dokumentacją były stosowane do odpowiednich dokumentów i obejmowały:a) dokumenty proceduralne opisujące system jakości związany z cyklem życia oprogramowania;

b) dokumenty opisujące planowanie i przebieg wszystkich działań dostawcy oraz jego współpracy z nabywcą;c) takie dokumenty wyrobu opisujące każdy wyrób programowy, jak:- dane wejściowe do etapu opracowywania;- dane wyjściowe z etapu opracowywania;

- plany i wyniki weryfikacji i zatwierdzania;

- dokumentacja dla nabywcy i użytkownika;

- dokumentacja dotycząca obsługiwania.

 

6.2.3 Zatwierdzanie i wydawanie dokumentu

Zaleca się, aby wszystkie dokumenty były przed wydaniem przeglądane i zatwierdzane przez upoważniony personel. Zaleca się stosowanie procedur zapewniających, że:

a) stosowne wydania określonych dokumentów są dostępne w odpowiednich miejscach, gdzie są wykonywane operacje istotne dla efektywnego funkcjonowania systemu jakości;

b) przestarzałe dokumenty są natychmiast usuwane z odpowiednich miejsc, w których były wydane lub są stosowane.

Zaleca się, aby tam, gdzie wykorzystywane są pliki komputerowe szczególną uwagę poświęcono procedurom zatwierdzania, dostępu, dystrybucji i archiwizowania.

6.2.4 Zmiany/ modyfikacje dokumentów

Zmiany w dokumentach powinny być przeglądane i zatwierdzane przez upoważniony personel tej samej organizacji, która dokonała pierwotnego przeglądu i zatwierdzenia, chyba że wyraźnie określono to inaczej. Personel ten powinien mieć dostęp do odpowiednich podstawowych informacji, na podstawie których ma być dokonany przegląd i zatwierdzenie.

Jeżeli jest to wykonalne, istota zmiany powinna być przedstawiona w dokumencie lub w odpowiednich załącznikach.

Powinien być sporządzony wykaz zmian lub równoważna procedura nadzoru nad dokumentami, umożliwiająca ich bieżący przegląd w celu wyeliminowania tych dokumentów, które nie mają już zastosowania. Dokumenty powinny być wydawane ponownie, gdy jest to uzasadnione ilością dokonanych zmian. [ISO 9001:1987, 4.5.2]

6.3 Zapisy dotyczące jakości

Dostawca powinien wprowadzić i przestrzegać procedur identyfikowania, gromadzenia, oznaczania, porządkowania, przechowywania, utrzymywania i dysponowania zapisami dotyczącymi jakości.

Zapisy dotyczące jakości powinny być prowadzone w celu zaprezentowania osiągnięcia wymaganej jakości oraz skuteczności działania systemu jakości. Stosowne zapisy dotyczące jakości u poddostawców powinny być częścią składową tych danych.

Wszystkie zapisy dotyczące jakości powinny być czytelne i umożliwiać jednoznaczne odniesienie do wyrobu, którego dotyczą. Zapisy dotyczące jakości powinny być przechowywane i utrzymywane w taki sposób, aby były łatwe do odszukania, w warunkach zapewniających zminimalizowane możliwości ich zniszczenia lub uszkodzenia oraz zapobiegających ich utracie. Okres przechowywania zapisów dotyczących jakości powinien być ustalony w formie pisemnej. Jeżeli jest to zawarte w umowie, zapisy dotyczące jakości powinny być udostępnione nabywcy lub jego przedstawicielowi na czas uzgodniony w celu dokonania oceny. [ISO 9001:1987, 4.16]

6.4 Pomiary

6.4.1 Pomiary dotyczące wyrobu

Zaleca się, aby informacje dotyczące stosowanych miar były przekazywane i wykorzystywane do zarządzania procesem opracowywania i dostarczania. Zaleca się, aby zastosowane miary były odpowiednie dla danego wyrobu programowego.

Nie ma obecnie powszechnie akceptowanych jednostek miar dotyczących jakości oprogramowania. Niemniej, jako minimum, zaleca się stosowanie miar, które pozwalałyby na określenie błędów i wad występujących w opisywanym obszarze z punktu widzenia klienta. Zaleca się, aby wybrane miary były tak opisane, by wyniki były porównywalne.

Zaleca się, aby dostawca gromadził dane ilościowe dotyczące jakości wyrobów programowych. Ma to na celu:

a) gromadzenie danych i przekazywanie informacji dotyczących wartości wynikających ze stosowanej miary, na podstawie stałych zasad;b) określanie aktualnego poziomu wykonania w odniesieniu do każdej stosowanej miary;

c) podejmowanie działań naprawczych w przypadku stwierdzenia, że poziom ten odbiega od założonego;

d) określenie i wyrażenie, w jednostkach wynikających z przyjętych miar, celów, jakie mają być osiągnięte w procesie doskonalenia.

6.4.2 Pomiary dotyczące procesu

Zaleca się, aby dostawca określał jakość procesu opracowywania i dostarczenia w sposób ilościowy. Zaleca się, aby przyjęte miary odzwierciedlały:a) prawidłowość opracowywania, przez umieszczenie w dotyczącym go harmonogramie informacji dotyczących realizacji poszczególnych etapów oraz osiągania celów jakościowych w trakcie tego procesu;

b) efektywność opracowywania w zakresie zmniejszania prawdopodobieńistwa wprowadzenia błędu lub niewykrycia wprowadzonego błędu. Podobnie, jak w przypadku miar dotyczących wyrobu, istotną sprawą jest to, że poziomy wykonania są znane, a ich znajomość może być wykorzystana do sterowania procesem i jego doskonalenia. Mniej ważny jest fakt, że stosowana jest taka, a nie inna miara. Zaleca się, aby wybór miar odpowiadał potrzebom wynikającym z charakteru stosowanego procesu i, jeżeli to możliwe, miał bezpośredni wpływ na jakość dostarczanego oprogramowania. W odniesieniu do różnych wyrobów programowych, wytwarzanych przez tego samego dostawcę, odpowiednie mogą być różne miary.

6.5 Zasady, praktyki i reguły

W celu zapewnienia efektywności systemu jakości opisanego w niniejszej części normy ISO 9000 zaleca się, aby dostawca przewidział i stosował odpowiednie zasady, praktyki i reguły działania. Zaleca się, aby dostawca dokonywał przeglądu zasad, praktyk i reguł oraz w razie potrzeby przeprowadzał ich nowelizację.

6.6 Narzędzia i techniki

W celu zapewnienia efektywności wytycznych tworzenia systemu jakości zawartych w niniejszej części normy ISO 9000 zaleca się, aby dostawca stosował odpowiednie narzędzia, urządzenia i techniki. Te narzędzia, urządzenia i techniki mogą być skuteczne zarówno w 72rządzaniu, jak i podczas opracowywania wyrobu. W razie potrzeby zaleca się, aby dostawca ulepszał stosowane narzędzia i techniki.

6.7 Zakupy

6.7.1 Postanowienia ogólne

Zaleca się aby, dostawca zapewnił, że zakupiony wyrób lub usługa spełnia ustalone wymagania. Zaleca się, aby dokumenty dotyczące zakupów zawierały dane jasno określające zamówiony wyrób lub usługę. Przed wydaniem dokumentów dotyczących zakupów zaleca się, aby dostawca dokonał przeglądu

tych dokumentów pod kątem powyższych wymagań i zatwierdził je.

UWAGA 7 Wyrób zakupiony przez dostawcę może być jednostką programową i/lub sprzętu przeznaczoną do włączenia jej do wyrobu finalnego lub narzędziem przeznaczonym do wykorzystania w trakcie opracowywania wymaganego wyrobu.

6.7.2 Ocena poddostawców

Dostawca powinien wybierać poddostawców na podstawie ich zdolności do .spełniania wymagań zawartych w umowach, w tym wymagań jakościowych. Dostawca powinien stworzyć i prowadzić zapisy dotyczące zaakceptowanych poddostawców.

Wybór poddostawców oraz ryp i zakres kontroli sprawowanej przez dostawcę powinien być uzależniony od typu wyrobu i, jeżeli jest to uzasadnione, od danych dotyczących uprzednio prezentowanych przez poddostawcę możliwości i dokonań.

Dostawca powinien zapewnić skuteczność nadzoru w ramach systemu jakości. [ISO 9001:1987, 4.6.2]

6.7.3 Zatwierdzanie zakupionego wyrobu

Dostawca jest odpowiedzialny za zatwierdzanie prac wykonywanych przez poddostawców. Może to wymagać od dostawcy dokonywania przeglądów prac projektowych i innych, w ramach własnego systemu jakości i, jeśli ma to miejsce, zaleca się, aby takie wymagania były włączone do umowy z poddostawcą. Podobnie, zaleca się włączenie wszelkich wymagań dotyczących badań odbiorczych prowadzonych przez dostawcę, w odniesieniu do prac wykonanych przez poddostawcę.

Jeżeli jest to ustalone w umowie, zaleca się, aby nabywca lub jego przedstawiciel miał prawo do sprawdzenia u źródła lub po otrzymaniu dostawy, czy zakupiony wyrób jest zgodny z ustalonymi wymaganiami. Zatwierdzenie przez nabywcę może być niewystarczające do zwolnienia dostawcy z odpowiedzialności za dostarczenie wyrobu możliwego do przyjęcia, ani też do wykluczenia możliwości późniejszego odrzucenia.

Jeżeli nabywca lub jego przedstawiciel dokonuje zatwierdzenia w zakładzie poddostawcy, to nie zaleca się, aby dostawca wykorzystywał to jako dowód skuteczności sterowania jakością przez poddostawcę.

 

6.8 Wyrób programowy włączany do dostaw

Od dostawcy czasami wymaga się, aby wykorzystał lub włączył do dostaw wyroby programowe dostarczone przez nabywcę lub stronę trzecią. Zaleca się, aby dostawca wprowadził i przestrzegał procedur zatwierdzania, przechowywania, ochrony i obsługiwania takiego wyrobu. Zaleca się uwzględniać istnienie takiego wyrobu programowego podczas dokonywania uzgodnień dotyczących obsługiwania dostarczanego wyrobu.

Zaleca się, aby informacja o każdym wyrobie nie nadającym się do wykorzystania, a dostarczonym przez nabywcę, była zapisana i przekazana nabywcy. Zatwierdzenie przez dostawcę nie zwalnia nabywcy z odpowiedzialności za dostarczenie wyrobu możliwego do przyjęcia.

6.9 Szkolenie

Zaleca się wprowadzenie i przestrzeganie przez dostawcę procedur określania potrzeb w zakresie szkolenia oraz zapewnienie szkolenia całego personelu zaangażowanego w działania mające związek z jakością. Zaleca się, aby personel wykonujący wyznaczone, określone zadania był dobierany stosownie do wymagań na podstawie właściwego wykształcenia, wyszkolenia i/ lub doświadczenia.

Przy określaniu tematyki szkoleń i przydzielaniu personelowi poszczególnych tematów zaleca się wziąć pod uwagę narzędzia, techniki, metodologie i środki techniki komputerowej wykorzystywane podczas opracowywania i zarządzania oprogramowaniem. Czasami wymagane jest szkolenie w zakresie wiedzy i umiejętności dotyczących określonych obszarów, w których ma być zastosowane oprogramowanie. Zaleca się przechowywanie odpowiednich zapisów dotyczących szkolenia/ doświadczenia.

Strona 1

Firma Handlowa "Mika"	 [phone]	[phone]
Grażyna Romanowicz-Mika		[phone]
ul. Parkowa 12		[e-mail]
43-365 Wilkowice	*	http://www.mika.com.pl

---