Dr Karol Chrabański Śląska WyŜsza Szkoła Zarządzania im. Generała Jerzego Ziętka w Katowicach ul. Krasińskiego 2, Tel.: 603-977-445 e-mail: karol@omi4.net Model semantyczny interpretacji norm ISO serii 9000 w procesie przejścia od Systemu Zarządzania Jakością do Systemu Zarządzania Wiedzą. Na przykładzie Organizacji Wytwarzającej Oprogramowanie Streszczenie Artykuł wskazuje na sposób przejścia od Systemu Zarządzania Jakością SZJ) stosowanego w Organizacji Wytwarzającej Oprogramowanie(OWO) do Systemu Zarządzania Wiedzą ( SZW) w tejŝe organizacji. Po czym w ramach SZW przedstawiony jest próba określenia elementów struktury wiedzy. 1. Organizacja Wytwarzająca Oprogramowanie w Gospodarce Opartej na Wiedzy Aktualnie autorzy licznych publikacji nie podejmują w zasadzie dyskusji co do faktu istnienia społeczeństwa informacyjnego. Proces ten zapoczątkowany został w drugiej połowie XX wieku i trwa nadal. Za Herbertem Kubickim moŝna przyjąć, Ŝe społeczeństwo informacyjne jest traktowane jak formacja społeczno-gospodarcza, w której produktywne wykorzystanie zasobu jakim jest informacja oraz intensywna pod względem wiedzy produkcja, odgrywają dominującą rolę 1. Stąd moŝna uŝyć określenia, Ŝe społeczeństwo informacyjne tworzy Gospodarkę Opartą na Wiedzy (GOW). Podstawowymi filarami GOW są: system innowacyjności, system edukacyjny, otoczenie instytucjonalno-biznesowe, aspekt 1 J.S. Nowak: Społeczeństwo Informacyjne-geneza i definicje;[w:] praca zbiorowa pod redakcją J.S. Nowak, G. Bliźniuk: Społeczeństwo informacyjne, PTI-Oddział Górnośląski, Katowice 2005, s. 40 1
regionalny, system informacyjno-komunikacyjny i wreszcie zarządzanie wiedzą na poziomie organizacji 2. Ten ostatni filar wymaga szczególnej uwagi. W.M. Grudzewski i I.K. Hejduk twierdzą odnośnie poziomu organizacji, Ŝe: 1. kształtowanie gospodarki opartej na wiedzy powinno przede wszystkim odbywać się na poziomie poszczególnych organizacji 2. trudno sobie wyobrazić gospodarkę opartą na wiedzy bez organizacji, szczególnie przedsiębiorstw, które skutecznie zarządzają wiedzą 3. wydaje się wręcz, Ŝe to właśnie na poziomie poszczególnych organizacji zarządzanie wiedzą, jest najbardziej efektywne Natomiast w niniejszym artykule filar przedsiębiorstwa jest jeszcze bardziej uszczegółowiony. Mianowicie jest nim OWO, która oferuje-po wykonaniu odpowiednich procesów - klientom wyrób w postaci oprogramowania. Jest to specyficzny wyrób, bowiem oprogramowanie jest najlepszym przykładem produktu opartego na wiedzy. Niemal w całości bowiem składa się z wiedzy (podobnie jak doradztwo-konsulting, projekty z zakresu reklamy, architektury i technologii) 3. OWO jest organizacją opartą na wiedzy, bowiem charakteryzuje się następującymi cechami 4 : 1. wytwarzają produkty bogate w wiedzę, tj. takie, których ponad połowa wartości stanowi wiedza lub dostarczają usługi oparte na wykorzystaniu wiedzy w większym stopniu niŝ pracy fizycznej 2. zatrudniają wysokiej klasy specjalistów, tzw. pracowników wiedzy, stanowiących trzon spośród wszystkich zatrudnionych 3. o ich wartości rynkowej przede wszystkim przesądza wartość kapitału intelektualnego. Wartość księgowa jest co najmniej dwa razy mniejsza, aniŝeli wartość rynkowa. MoŜna zaryzykować twierdzenie, Ŝe współcześnie wiele produktów ma tak znaczące znaczenie dla klientów, poniewaŝ zawiera w sobie oprogramowanie. Przyjmując za normą 2 W.M.Grudzewski, I.K.Hejduk: Zarządzanie wiedzą w przedsiębiorstwach. Difin, Warszawa 2004, s. 15-19 3 A. Fazlagić: Systematyzacja pojęć związanych z zarządzaniem wiedzą, Problemy Jakości 3/2005 4 W.M. Grudzewski, I.K. Hejduk: Zarządzanie wiedza w przedsiębiorstwach..., s.135 2
ISO/IEC 12207 ( Technologia informacyjna procesy cyklu Ŝycia oprogramowania ), Ŝe oprogramowanie to to samo co produkt programistyczny. MoŜna go zdefiniować jako zestaw programów komputerowych, procedur i ewentualnie związanej z nim dokumentacji i danych. Nawiązując do normy ISO/IEC 12207 moŝna przyjąć definicję OWO jako organizacji, która zawiera kontrakt z nabywcą na dostawę na warunkach określonych w kontrakcie-systemu, produktu programistycznego lub usługi programistycznej. Ta ostatnia wg wspomnianej normy - to wykonanie czynności, prac lub obowiązków związanych z produktem programistycznym, takich jak rozwój, konserwacja i obsługa. W niniejszym artykule przyjmuje się definicję zarządzania wiedzą podaną przez naukowców z Cranfield School of Management w Wielkiej Brytanii. Jest to równieŝ definicja, za którą w toku badań - opowiedzieli się menedŝerowie. W rezultacie przyjęto, Ŝe zarządzanie wiedzą to ogół procesów umoŝliwiających tworzenie, upowszechnianie i wykorzystanie wiedzy o realizacji celów organizacji 5. Aczkolwiek naleŝy równieŝ zauwaŝyć, Ŝe moŝna przyjąć pojęcie wiedzy jako podstawowe (pierwotne). Tym samym ograniczając się jedynie do jego wyjaśnienia i rozgraniczenia od innych pojęć pokrewnych 6. W praktyce często zarządzanie wiedzą jest związane z 7 : 1. identyfikacją (mapowaniem) wiedzy (inaczej lokalizowaniem) 2. tworzeniem wiedzy (innowacyjność) 3. ułatwianiem dostępu do informacji 4. dzielenie się wiedzą 5. upowszechnianie najlepszych rozwiązań w ramach tej samej organizacji. Oprogramowanie staje się coraz bardziej powszechnym elementem stosowanym przez współczesne organizacje. Jest ono wynikiem-rezultatem prac podejmowanych przez zespołyfirmy specjalistów (specjalistyczne). Coraz większa liczba OWO posiada zaprojektowany, udokumentowany, wdroŝony i certyfikowany System Zarządzania Jakością (SZJ) 5 M.Morawski: Ilościowe zarządzanie wiedzą podejście zachodnie, [w:] praca zbiorowa pod redakcją K.Perechudy: Zarządzanie wiedzą w przedsiębiorstwie, Wydawnictwo Naukowe PWN, Warszawa 2005, s. 74 6 J. Gołuchowski: Technologie informatyczne w zarządzaniu wiedzą w organizacji, Wydawnictwo AE Katowice, Katowice 2005 rok, s.18 7 A. Fazlagić, tamŝe 3
spełniających wymagania międzynarodowych norm z serii ISO 9001:2000. Przyjmuje się, Ŝe SZJ to system zarządzania (system do ustanawiania polityki i celów, i osiągania tych celów) do kierowania organizacją (grupa ludzi i infrastruktura, z przypisaniem odpowiedzialności, uprawnień i powiązań) i jej nadzorowania w odniesieniu do jakości. Wymagania normy ISO 9001:2000 zostały uzupełnione o zalecenia podane w normie ISO/IEC 90003 (software engineering Guidelines for the application of ISO 9001:2000. to computer software ). Dla lepszego zobrazowania obszernej tematyki SZJ całość wymagań i zaleceń podzielono na części. Dokonano podziału w oparciu o przyjęte kryteriaposzczególnych procesów. Całość podziału procesów przedstawia rysunek 1 ( rysunki są umieszczone na końcu artykułu). Podziału procesów uwidocznionych na rysunku 1- dokonano w oparciu o podane poniŝej wybrane kryteria. Oto one: 1. procesy zarządzania sprowadzają się do podjęcia przez najwyŝsze kierownictwo decyzji konstytuujących SZJ. Obejmują one : Wymagania dotyczące dokumentacji, do których moŝna zaliczyć: postanowienia ogólne [4.2.1] księga jakości [4.2.2] Odpowiedzialność kierownictwa do których moŝna zaliczyć: zaangaŝowanie kierownictwa [5.1] orientacja na klienta [5.2] polityka jakości [ 5.3] planowanie [5.4] odpowiedzialność, uprawnienia i komunikacja [5.5] przegląd zarządzania [5.6] 2. procesy doskonalące, które obejmują: ciągłe doskonalenie [8.5.1], działania korygujące [8.5.2], działania zapobiegawcze [8.5.3] 3. procesy główne dotyczą realizacji wyrobu (tutaj: oprogramowania), poniekąd obrazują cykl Ŝycia wyrobu, począwszy od określenia wymagań dotyczących wyrobu, poprzez 4
przegląd wymagań dotyczących wyrobu, planowanie realizacji wyrobu, zakupy, produkcję i dostarczanie usługi, do działań po dostawie. Obejmują: planowanie realizacji wyrobu [7.1] procesy związane z klientem [7.2] projektowanie i rozwój [7.3] zakupy [7.4] produkcja i dostarczanie usługi [7.5] nadzorowanie wyposaŝenie do monitorowania i pomiarów [7.6] 4. procesy pomocnicze - wspomagają poprawne działanie procesów zarządzania, procesów głównych - realizacji wyrobu, procesów doskonalących. MoŜna je podzielić na trzy podgrupy: pierwszą: procesy pomocnicze zarządzanie zasobami. Dotyczą takich zasobów jak: zasoby ludzkie [6.2], środowisko pracy [6.3], infrastruktura [6.4] drugą: procesy pomocnicze zarządzanie dokumentacją. Obejmują nadzór nad dokumentacją [4.2.3] i nadzór nad zapisami [4.2.4] trzecią: procesy pomocnicze - monitorowanie, pomiary i analiza. Obejmują one: monitorowanie i pomiary procesów [8.2.3] i wyrobu [8.2.4], nadzorowanie wyposaŝenia do monitorowania i pomiarów [7.6], nadzór nad wyrobem niezgodnym [8.3], audity wewnętrzne [8.2.2], analizowanie danych [8.4], badanie zadowolenia klienta.[8.2.1]. NaleŜy wskazać,ŝe bezsprzecznie występują powiązania pomiędzy SZJ a SZW 8. W oparciu o tą przesłankę zaproponowano sposób budowy SZW dla OWO stosujących wymagania i zalecenia podane w SZJ. Całość przedstawia rysunek nr 2. Uwzględniono na nim następujące elementy: 8 K.Chrabański: Systemy zarządzania jakością i systemy zarządzania wiedzą. Próba zdefiniowania relacji na przykładzie organizacji wytwarzającej oprogramowanie, [w:] praca zbiorowa pod redakcją E. Skrzypek, Materiały konferencji naukowej Intellect 2005 nt. Kapitał intelektualny jako szansa na poprawę jakości zarządzania w warunkach globalizacji. Zakład Ekonomiki Jakości i Zarządzania Wiedzą Wydział Ekonomiczny UMCS Lublin, Kazimierz Dolny, 25-27 listopada 2005 roku 5
1. opracowanie załoŝeń modelu semantycznego prezentacji wymagań normy ISO 9001:2000 i zaleceń normy ISO /IEC 90003 2. przedstawienie z pomocą modelu semantycznego poszczególnych procesów ( zarządzania, doskonalące, główne, itd. ) 3. opracowanie mapy poszczególnych procesów z uwzględnieniem załoŝeń modelu semantycznego 4. opracowanie potencjalnych obszarów decyzyjnych dla poszczególnych procesów SZJ 5. zdefiniowanie elementów wiedzy SZW Przedstawiony pięcioetapowy sposób budowania SZW dla OWO zostanie uszczegółowiony poprzez odniesienie poszczególnych etapów do wybranego fragmentu SZJ przewidzianego dla OWO. Uszczegółowienie zostało przedstawione w postaci kolejnych załączników. PoniŜsze zestawienie obrazuje zawartość poszczególnych załączników: a) załącznik nr 1: załoŝenia modelu semantycznego prezentacji wymagań normy ISO 9001:2000 i zaleceń normy ISO /IEC 90003 b) załącznik nr 2: przedstawienie z pomocą modelu semantycznego wybranych procesów głównych dla punktów normy 7.3.4 do 7.3.7 c) c)załącznik nr 3: opracowanie mapy poszczególnych procesów z uwzględnieniem załoŝeń modelu semantycznego dla 7.3.4 do 7.3.7 d) załącznik nr 4 : opracowanie potencjalnych obszarów decyzyjnych dla poszczególnych procesów SZJ dla punktów 7.3.1 do 7.3.7 e) załącznik nr 5: zdefiniowanie elementów wiedzy SZW dla wybranego obszaru decyzyjnego dotyczącego punktów normy 7.3.1 2. Zakończenie W Gospodarce Opartej na Wiedzy (GOW) na poziomie przedsiębiorstw-jak się podaje w literaturze- najskuteczniej zarządza się wiedzą Jednym z przykładów przedsiębiorstw, których działalność niemal w całości opiera się na wiedzy są Organizacje Wytwarzające Oprogramowanie ( OWO). Niektóre spośród nich celem skuteczniejszego zaspokajania potrzeb klientów zaprojektowały, udokumentowały, wdroŝyły i utrzymują Systemy 6
Zarządzania Jakością ( SZJ) Dla tej grupy przedsiębiorstw ( OWO oraz SZJ) zostanie podjęta próba zdefiniowania elementów wiedzy SZW, co wynika z faktu ogromnego znaczenia jakie ma dla nich wiedza. Zdefiniowane elementy wiedzy posłuŝą do wykonania analiz SZW Przedstawiona metodyka ( sposób ) weryfikowana w trakcie aktualnie prowadzonych postępowania jest obecnie praktycznie pod kierunkiem autora artykułu usług doradczych związanych z opracowaniem i pomocą we wdroŝeniu innowacyjnych rozwiązań z zakresu zarządzania cyklem Ŝycia produktu softwarowego. Całość prac jest odniesiona do telemetrycznych systemów informatycznych. Zakres projektu obejmuje zaprojektowanie, wdroŝenie i ocenę systemu jakości związanego z cyklem Ŝycia produktów dla wszystkich sekcji działu telemetrii tj. badań i rozwoju, produkcji i sprzedaŝy, utrzymania, sekcji testów Ŝycia produktów dla wszystkich sekcji działu telemetrii tj. badań i rozwoju, produkcji, sprzedaŝy, utrzymania i planowanej sekcji testów. Bibliografia 1. Chrabański K., Systemy zarządzania jakością i systemy zarządzania wiedzą. Próba zdefiniowania relacji na przykładzie organizacji wytwarzającej oprogramowanie, [w:] praca zbiorowa pod redakcją E. Skrzypek, Materiały konferencji naukowej Intellect 2005 nt. Kapitał intelektualny jako szansa na poprawę jakości zarządzania w warunkach globalizacji. Zakład Ekonomiki Jakości i Zarządzania Wiedzą Wydział Ekonomiczny UMCS Lublin, Kazimierz Dolny, 25-27 listopada 2005 roku 2. Fazlagić A., Systematyzacja pojęć związanych z zarządzaniem wiedzą, Problemy Jakości 3/2005 3. Gołuchowski J., Technologie informatyczne w zarządzaniu wiedzą w organizacji, Wydawnictwo AE Katowice, Katowice 2005 4. Grudzewski W.M., Hejduk I.K., Zarządzanie wiedzą w przedsiębiorstwach, Difin, Warszawa 2004 6.International Standard ISO/IEC 90003: Software engineering. Guidelines for the application of 9001:2000to computer software. First edition 2004.02.15 7. Kisielnicki J., System pozyskiwania i zarządzania wiedzą we współczesnych organizacjach, [w:] Zarządzanie wiedzą we współczesnych organizacjach, Oficyna Wydawnicza WyŜszej Szkoły Handlu i Prawa im. R. Łazarskiego, Warszawa 2003 8.. Morawski M., Ilościowe zarządzanie wiedzą podejście zachodnie, [w:] praca zbiorowa pod redakcją K.Perechudy: Zarządzanie wiedzą w przedsiębiorstwie, Wydawnictwo Naukowe PWN, Warszawa 2005 9. Nowak J.S., Społeczeństwo Informacyjne-geneza i definicje;[w:] praca zbiorowa pod redakcją J.S. Nowak, G. Bliźniuk: Społeczeństwo informacyjne, PTI-Oddział Górnośląski, Katowice 2005 10. PN-EN ISO 9001:2000 Systemy zarządzania jakością. Wymagania, Polski Komitet Normalizacyjny, Warszawa 2001 7
8
Odpowiedzialność kierownictwa Inne 5 Dokumentacja SZJ 4.2.1 Odpowiedzialność kierownictwa (zapewnienia) 5 Działania korygujące 8.5.2 Działania 8.5.3 zapobiegawcze Ciągłe 8.5.1 doskonalenie Wyznaczenie pełnomocnika 5.5.2 Przeprowadzenie przeglądu SZJ 5.1 d Procesy zarządzania Procesy doskonalące Procesy główne realizacja wyrobu 7 Procesy związane z klientem, w tym komunikacja 7.2 Procesy pomocnicze zarządzanie zasobami 6 Procesy pomocnicze 4. 2 zarządzanie dokumentacją Procesy pomocnicze monitorowanie, pomiar i analiza 8 Zasoby 6.2 ludzkie Środowisko 6.3 pracy 6.4 Infrastruktura Nadzór 4.2.3 nad dokumentacją Nadzór 4.2.4 nad zapisami Nadzorowanie wyposaŝenia do monitorowania i pomiarów 7.6 Monitorowanie i pomiary wyrobu 8.2.4 Nadzór nad wyrobem niezgodnym 8.3 Audity 8.2.2 wewnętrzne Badanie zadowolenia klienta 8.2.1 Analizowanie danych 8.4 Klient wymagania Klient zadowolenie Określenie 7.2.1 wymagań dotyczących wyrobu Przegląd 7.2.2 wymagań dotyczących wyrobu Planowanie 7.1 realizacji wyrobu Bez wymogu projektowania Zakupy 7.4 Z wymogiem 7.3 projektowania i rozwoju Produkcja i 7.5. dostarczanie usługi Działania po dostawie Hardware Software Monitorowanie i pomiary procesu 8.2.3 Rysunek 1. Mapa procesów dla organizacji wytwarzającej oprogramowanie spełniającej wymagania ISO 9001:2000 i zalecenia ISO/IEC 90003. Źródło: Opracowanie własne. K. Chrabański: Mapowanie procesów systemu zarządzania jakością zgodnego ze standardem ISO 9001:2000 przeznaczonego dla wytwórców oprogramowania. [w:] praca zbiorowa pod redakcją M. Goliński, J.K. Grabara, J.S. Nowak: Informatyka i efektywność systemów, PTI-Oddział Górnośląski, Katowice 2005, s. 261-268
Rysunek 1 2
Rysunek 2 Kryteria podziału procesów Podział procesów SZJ procesy główne procesy pomocnicze procesy zarządzania procesy doskonalące ISO 9001:2000 ISO/IEC 90003 9 zasad budowy modelu Opracowanie załoŝeń modelu semantycznego prezentacji wymagań normy ISO 9001:2000 i zaleceń ISO/IEC 90003 Przedstawienie z pomocą modelu semantycznego poszczególnych procesów SJZ Poszczególne Procesy SZJ Opracowanie mapy poszczególnych procesów z uwzględnieniem załoŝeń modelu Mapa procesów Opracowanie potencjalnych obszarów decyzyjnych dla poszczególnych procesów SZJ Potencjalne obszary decyzyjne Hierarchia poziomów opisu wiedzy wg. K. Wiig Zdefiniowanie elementów wiedzy SZW dziedzina region segment element fragment atom W I E D Z Y Analiza elementów wiedzy SZW Rysunek 2. Elementy uwzględniane przy określaniu sposobu budowy SZW dla OWO stosujących SZJ. Źródło : Opracowanie własne. 8
Załącznik nr 1: ZałoŜenia modelu semantycznego prezentacji wymagań normy ISO 9001:2000 i zaleceń normy ISO /IEC 90003 Normy ISO serii 9000 pisane są jak juŝ wspomniano - językiem zwięzłym, o określonym (zwykle duŝym) stopniu uogólnienia. Stąd teŝ, mając na uwadze zwiększenie komunikatywności przekazu zawartości norm serii ISO w odniesieniu do OWO zaproponowano semantyczne (znaczeniowe) ujęcie wymagań podanych w normie ISO 9001:2000 z jednoczesnym uwzględnieniem zaleceń podanych w normie ISO/IEC 90003. W praktyce semantyczne ujęcie wymagań i zaleceń podanych we wskazanych normach ISO uzupełniono przyjęciem następujących dodatkowych zasad: 1. wyraźne oddzielenie zawartości wymagań ujętych w normie ISO 9001: 2000 od zaleceń podanych w normie ISO /IEC 90003. Zalecenia na rysunkach są oznaczone przerywaną linią. 2. poszczególne punkty wymagań normy ISO 9001:2000 i zaleceń z normy ISO/IEC 90003 są przyporządkowane do procesów podanych w ramach zaprezentowanej juŝ mapy procesów (zarządzania, doskonalące, itd.). 3. kaŝdy proces uwidoczniony w mapie procesów jest scharakteryzowany za pomocą opisu słownego i rysunku. MoŜe się zdarzyć, Ŝe niektóre procesy są uwidocznione z pomocą kilku rysunków i tekstów je objaśniających. W takich przypadkach kierowano się względami technicznymi, tzn. wyrazistością przekazu. 4. oznaczenie numeryczne poszczególnych wymagań podanych w normie ISO 9001:2000 5. z zaleceniami podanymi w ISO/IEC 90003 są zachowane na prezentowanych rysunkach. 6. podjęto próbę udostępnienia treści poszczególnych punktów normy poprzez - jak to wskazano - charakterystykę semantyczną (znaczeniową) zawartą w jej treści. WyróŜniono następujące elementy: postulaty, czyli Ŝądania lub wymagania oraz kwestie, czyli sprawy, na które wypada dodatkowo zwrócić uwagę i ewentualnie podjąć rozstrzygnięcia 9
7. postulaty mogą występować zarówno w wymaganiach normy ISO 9001:2000 jaki i w zaleceniach podanych w ISO/IEC 90003 8. zarówno do postulatów, jak i kwestii moŝna przypisać róŝne znaczenie dołączonych treści (rozwinięć) podane przez normę ISO 9001:2000 oraz zalecenia ISO/IEC 90003. Wspomniane rozwinięcia mogą dotyczyć: proponowanego sposobu realizacji, uszczegółowienia zakresu, dodatkowych uwag odnośnie sposobu realizacji, przykładów, odsyłaczy do innych punktów normy ISO 9001: 2000, odsyłaczy do innych norm 9. dla poszczególnych punktów normy ISO 9001:2000 i powiązanych z nim zaleceń podane powyŝej rozwinięcia mogą występować w róŝnej ilości (np. kilka sposobów uszczegółowienia zakresu, kilka przykładów, itd.) i w róŝnym natęŝeniu (np. wyłącznie są podane przykłady lub kilka sposobów realizacji, kilka dodatkowych uwag, odsyłacz do innej aniŝeli - ISO 9001:2000 normy). 10. odsyłacze do innych punktów normy ISO 9001:2000 i do innych norm mają róŝną postać graficzną. Postać graficzna odsyłaczy dla postulatów i dla kwestii przyjmuje taką samą postać. PoniŜej podano oznaczenia graficzne stosowane na rysunkach - dla postulatu oraz kwestii oraz powiązanych z nimi rozwinięć. A. Postulat P Proponowany sposób realizacji: 2. Uszczegółowienie zakresu: 10
3. Dodatkowe uwagi odnośnie sposobu realizacji: 4. Przykłady: NP 5. Odsyłacze do innych punktów normy ISO 9001:2000: 6. Odsyłacze do innych norm: B. Kwestie 1. Proponowany sposób realizacji: 2. Uszczegółowienie zakresu: Dodatkowe uwagi odnośnie sposobu realizacji: 4. Przykłady: NP 5. Odsyłacze do innych punktów normy ISO 9001:2000: 6. Odsyłacze do innych norm: 11
Załącznik nr 2 Przedstawienie z pomocą modelu semantycznego wybranych procesów głównych dla punktów normy 7.3.4 do 7.3.7 PoniŜej przedstawiono postulaty i kwestie związane z procesami projektowania i rozwoju, z uwzględnieniem jedynie: przeglądu, weryfikacji, walidacji, nadzorowania zmian. Postulat 1 (9001:2000, p.7.3.4 Przegląd projektowania i rozwoju): na odpowiednich etapach naleŝy przeprowadzać systematyczne przeglądy projektowania i rozwoju zgodnie z zaplanowanymi ustaleniami (patrz 7.3.1 - Planowanie projektowania i rozwoju), w celu: oceny zdolności wyników projektowania i rozwoju do spełnienia wymagań, identyfikowania wszelkich problemów i proponowania niezbędnych działań. Postulat 2 (9001:2000, p.7.3.4 Przegląd projektowania i rozwoju): w przeglądach takich powinni brać udział przedstawiciele słuŝb związanych z etapem (etapami) projektowania i rozwoju podlegającym (podlegającymi) przeglądom. NaleŜy utrzymywać zapisy wyników przeglądów i wszelkich niezbędnych działań (patrz 4.2.4 - nadzór nad zapisami). Kwestia 1 (ISO/IEC 90003, p.7.3.4 - Przegląd projektowania i rozwoju): stopień formalności i rygoru działań związanych z procesami przeglądu powinien być odpowiedni do złoŝoności 12
wyrobu, wymagań jakościowych i stopnia ryzyka związanego z określonym zastosowaniem wyrobu. Kwestia 2 (ISO/IEC 90003, p.7.3.4 - Przegląd projektowania i rozwoju): Organizacja powinna ustalić procedury postępowania w przypadku wad procesów i wyrobów lub niezgodności stwierdzonych w trakcie tych działań (zob. 8.3). Zaleca się dokumentowanie tych procedur. Kwestia 3 (ISO/IEC 90003, p.7.3.4 - Przegląd projektowania i rozwoju): w trakcie przeglądów projektowania i rozwoju naleŝy brać pod uwagę takie kryteria, jak: wykonalność, bezpieczeństwo, zasady programowania i testowalność. W tym miejscu warto wskazać na dodatkowe informacje 9. Kwestia 4 (ISO/IEC 90003, p. 7.3.4 - Przegląd projektowania i rozwoju): przegląd projektowania i rozwoju powinien być dokonywany zgodnie z zaplanowanymi ustaleniami. Elementy przeglądu, które naleŝy rozwaŝyć (podane poniŝej podpunkty mają status dodatkowych uwag odnośnie sposobu realizacji): co naleŝy przeglądać, kiedy, jaki rodzaj przeglądu zastosować, np. demonstracja, formalne dowody poprawności, kontrola, przegląd oprogramowania i wspólne przeglądy, jakie grupy funkcjonalne będą rozwaŝane w kaŝdym rodzaju przeglądu, a jeśli ma się odbyć spotkanie w sprawie przeglądu jak będzie ono zorganizowane i prowadzone, jakie dokumenty naleŝy przedstawić, np. protokoły posiedzeń, kwestie, problemy, działania i stan działań, metody monitorowania stosowania zasad, praktyk i konwencji, mające zapewnić ich przestrzeganie, co zrobiono przed dokonaniem przeglądu, np. ustalenie celów, porządek obrad, wymagane dokumenty i zadania pracowników dokonujących przeglądu, co zrobiono w trakcie przeglądu, w tym stosowane techniki i zasady obowiązujące wszystkich uczestników, kryteria powodzenia przeglądu, jakie przewidziano działania po przeglądzie, mające zapewnić rozwiązanie problemów zidentyfikowanych w trakcie przeglądu. Kwestia 5 (ISO/IEC 90003, p.7.3.4 - Przegląd projektowania i rozwoju): dalsze działania projektowe i rozwojowe powinny następować tylko w przypadku, gdy rozumiane są konsekwencje wszystkich znanych wad, a ryzyko związane z kontynuacją jest znane i uzgodnione. Wszystkie wnioski powinny być odpowiednio rozpatrzone i rozstrzygnięte 10. Postulat 3 (ISO 9001:2000, p.7.3.5 Weryfikacja projektowania i rozwoju): weryfikację naleŝy przeprowadzać zgodnie z zaplanowanymi ustaleniami (patrz 7.3.1 - Planowanie 9 Są one zawarte w normie ISO/IEC 12207:1995 [11] i ISO/IEC 12207:1995/Poprawka 1:2002 [12] traktują zarządzenie projektem i przeglądy techniczne jako odrębne działania. 10 Odsyłacz do innych norm: ISO/IEC 12207:1995 [11], 5.3.4.2, 5.3.5.6, 5.3.6.7 (wymagania i oceny projektowania) i 6.6.3 (przeglądy techniczne) oraz ISO/IEC 12207:1995/Poprawka 1:2002 [12], F.2.6 (wspólne przeglądy); ISO/IEC TR 15271:1998 [21], Aneks A (procesy i wymagania jakości). 13
projektowania i rozwoju) w celu zapewnienia, Ŝe dane wyjściowe z projektowania i rozwoju spełniły wymagania określone w danych wejściowych do projektowania i rozwoju. Postulat 4 (ISO 9001:2000, p.7.3.5 Weryfikacja projektowania i rozwoju): naleŝy utrzymywać zapisy wyników weryfikacji i wszelkich niezbędnych działań (patrz 4.2.4 - Nadzór nad zapisami). Kwestia 6 (ISO/IEC 90003, p.7.3.5 - Weryfikacja projektowania i rozwoju): weryfikacja oprogramowania ma na celu zapewnienie zgodności wyniku działań projektowych i rozwojowych z wymaganiami ustalonymi na wejściu. Kwestia 7 (ISO/IEC 90003, p.7.3.5 - Weryfikacja projektowania i rozwoju): weryfikację naleŝy przeprowadzać odpowiednio w trakcie projektowania i rozwoju. Weryfikacja moŝe obejmować przeglądy danych wyjściowych projektowania i rozwoju (np. w formie kontroli i przeglądów oprogramowania), analizy, demonstracje, prototypy, symulacje i testy. Weryfikacja moŝe być prowadzona w oparciu o wyniki innych działań, np. oprogramowania z półki, produktów zakupionych i dostarczonych przez klientów. Kwestia 8 (ISO/IEC 90003, p.7.3.5 - Weryfikacja projektowania i rozwoju): w przypadkach uzasadnionych skalą, złoŝonością lub znaczeniem oprogramowania do weryfikacji naleŝy stosować określone metody zapewnienia jakości wyników, np. metryka złoŝoności, przeglądy równorzędne, opracowanie warunków/decyzji lub metody formalne. Kwestia 9 (ISO/IEC 90003, p.7.3.5 - Weryfikacja projektowania i rozwoju): tylko zweryfikowane dane wyjściowe powinny być przedkładane do odbioru i późniejszego stosowania. Wszystkie wnioski powinny być odpowiednio rozpatrzone i rozstrzygnięte 11. Postulat 5 (ISO 9001:2000, p.7.3.6 Walidacja projektowania i rozwoju): Walidację projektowania i rozwoju naleŝy przeprowadzać zgodnie z zaplanowanymi ustaleniami (patrz 7.3.1 - Planowanie projektowania i rozwoju) w celu zapewnienia, Ŝe wytworzony wyrób jest zdolny spełnić wymagania związane z wyspecyfikowanym zastosowaniem lub zamierzonym wykorzystaniem, jeŝeli jest znane. Postulat 6 (ISO 9001:2000, p.7.3.6 Walidacja projektowania i rozwoju). Wszędzie gdzie jest to wykonalne, walidacja powinna być zakończona przed dostawą lub wdroŝeniem wyrobu. Postulat 7 (ISO 9001:2000, p.7.3.6 Walidacja projektowania i rozwoju): naleŝy utrzymywać zapisy wyników walidacji i wszelkich niezbędnych działań (patrz 4.2.4). Kwestia 10 (ISO/IEC 90003, p.7.3.6.1 Walidacja): celem walidacji oprogramowania jest uzyskanie uzasadnionego przeświadczenia, Ŝe spełnia ono wymagania robocze. Kwestia 11 (ISO/IEC 90003, p.7.3.6.1 Walidacja): przed przedstawieniem produktu do odbioru przez klienta organizacja powinna dokonać walidacji eksploatacji produktu stosownie do jego określonego przeznaczenia, w warunkach podobnych do środowiska aplikacji określonego w kontrakcie. Wszelkie róŝnice między środowiskiem walidacji, a środowiskiem rzeczywistej aplikacji oraz ryzyko związane z takimi róŝnicami naleŝy zidentyfikować, uzasadnić i zarejestrować na moŝliwie wczesnym etapie cyklu Ŝycia. W trakcie walidacji 11 Dalsze informacje moŝna znaleźć w następujących normach: ISO/IEC 12207:1995 [11], 5.3 (rozwój) i 6.4 (weryfikacja) oraz ISO/IEC 12207:1995/Poprawka 1:2002 [12], F.1.3 (rozwój) i F.2.4 (weryfikacja). 14
moŝna dokonywać, stosownie do potrzeb, auditów lub ocen konfiguracji, przed wydaniem wersji podstawowej konfiguracji. Audity i oceny konfiguracji potwierdzają, w wyniku analizy zapisów przeglądów, kontroli i testów, Ŝe oprogramowanie odpowiada kontraktowym lub innym, określonym wymaganiom. MoŜe to wymagać analizy, symulacji lub emulacji w tych przypadkach, gdy walidacja nie jest wykonalna w warunkach eksploatacji. Kwestia 12 (ISO/IEC 90003, p.7.3.6.1 Walidacja): jeśli chodzi o rozwój (opracowanie) oprogramowania, waŝne jest, aby wyniki walidacji i wszelkie inne działania wymagane do spełnienia określonych wymagań były rejestrowane i sprawdzane po zakończeniu czynności. Kwestia 13 (ISO/IEC 90003, p.7.3.6.1 Walidacja): w niektórych przypadkach moŝe okazać się, Ŝe pełna walidacja oprogramowania za pomocą pomiaru i monitorowania nie jest moŝliwa lub wykonalna. Przykładem jest sytuacja, gdy nie moŝna poddać testom oprogramowania związanego z bezpieczeństwem w warunkach rzeczywistych bez ryzyka powaŝnych konsekwencji, względnie gdy te rzeczywiste warunki występują rzadko i trudno przeprowadzić ich symulację. Kwestia 14 (ISO/IEC 90003, p.7.3.6.1 Walidacja): nie mając moŝliwości przeprowadzenia testów niektórych wyrobów procesu programowania, organizacja zmuszona jest ustalić: w jakiej mierze moŝna mieć zaufanie do efektów rozwoju i do stosowanych narzędzi, jakiego rodzaju badania i analizy moŝna wykonać, aby zwiększyć przeświadczenie, Ŝe wyrób będzie działał prawidłowo w nietestowalnych warunkach, np. statyczna analiza kodu. Bez względu na to, jakie metody są stosowane, powinny one być współmierne z ryzykiem i konsekwencjami związanymi z niepowodzeniami w projektowaniu i rozwoju. Kwestia 15 (ISO/IEC 90003, p.7.3.6.2 Testowanie): walidację moŝna często przeprowadzić za pomocą testowania. Testy mogą być wymagane na kilku poziomach, począwszy od poszczególnych modułów oprogramowania po pełny wyrób procesu programowania. Istnieje kilka sposobów podejścia do testowania róŝniących się zakresem testów i stopniem kontroli nad otoczeniem testowym, danymi wejściowymi i wyjściowymi, złoŝonością wyrobu i ryzykiem związanym z jego stosowaniem. Planowanie testów powinno uwzględnić ich rodzaj, cele, kolejność i zakres testowania, okoliczności testu, dane testu i oczekiwane rezultaty. W planowaniu testów naleŝy zidentyfikować zasoby ludzkie i fizyczne niezbędne do przeprowadzenia testów oraz ustalić zakresy odpowiedzialności zaangaŝowanych osób. Kwestia 16 (ISO/IEC 90003, p.7.3.6.2 Testowanie): właściwe testowanie oprogramowania obejmuje ustalanie, dokumentowanie, przeglądanie i realizowanie planów w następującym zakresie (podane punkty mają status uszczegółowienia zakresu): testy jednostkowe, np. autonomiczne testy komponentów, testy integracyjne i systemowe, np. testy agregacji komponentów oprogramowania (i całego systemu), testy kwalifikacyjne, tj. testy kompletnego wyrobu przed dostawą mające potwierdzić spełnianie przez oprogramowanie określonych wymagań, testy przy odbiorze, tj. testy kompletnego wyrobu mające potwierdzić spełnianie przez oprogramowanie kryteriów odbioru. 15
Testowanie regresyjne naleŝy wykonywać w celu weryfikacji, czy moŝliwości oprogramowania nie zostały ograniczone wskutek wprowadzonej zmiany, lub w celu walidacji takiej zmiany. Testy odbiorcze są wykonywane w interesie klienta i mają na celu ustalenie dopuszczalności wyrobu. W zaleŝności od uzgodnień stron, odbiór moŝe nastąpić mimo określonych usterek lub odstępstw od wymagań. Kwestia 17 (ISO/IEC 90003, p.7.3.6.2 Testowanie): naleŝy określić i kontrolować narzędzia i środowisko wykorzystywane do testowania, a wszelkie ograniczenia w zakresie testowania naleŝy odnotować. Kwestia 18 (ISO/IEC 90003, p.7.3.6.2 Testowanie): procedury testowe powinny obejmować rejestrację i analizę wyników, a takŝe zarządzanie problemami i zmianami. Jednocześnie zwraca się uwagę na fakt, Ŝe dalsze informacje moŝna znaleźć w pozostałych normach 12. Postulat 8 (ISO 9001:2000, p.7.3.7 Nadzorowanie zmian w projektowaniu i rozwoju): zmiany w projektowaniu i rozwoju powinny być zidentyfikowane i powinny być utrzymywane zapisy. Postulat 9 (ISO 9001:2000, p.7.3.7 Nadzorowanie zmian w projektowaniu i rozwoju): zmiany naleŝy poddawać, odpowiednio, przeglądowi, weryfikacji i walidacji oraz naleŝy je zatwierdzać przed ich wdroŝeniem. Postulat 10 (ISO 9001:2000, p.7.3.7 Nadzorowanie zmian w projektowaniu i rozwoju): przegląd zmian w projektowaniu i rozwoju powinien obejmować ocenę wpływu zmian na części składowe i juŝ dostarczony wyrób. NaleŜy utrzymywać zapisy wyników przeglądu zmian i wszelkich niezbędnych działań (patrz 4.2.4 - Nadzór nad zapisami). Kwestia 19 (ISO 9001:2000, p.7.3.7 Nadzorowanie zmian w projektowaniu i rozwoju): w przypadku środowiska rozwoju (opracowania) oprogramowania, nadzór zmian w projektowaniu i rozwoju jest realizowany zwykle jako część zarządzania konfiguracją (zob. 7.5.3 - Identyfikacja i identyfikowalność). Kwestia 20 (ISO 9001:2000, p.7.3.7 Nadzorowanie zmian w projektowaniu i rozwoju): zmiany specyfikacji lub komponentów oprogramowania powinny zachowywać zgodność pomiędzy wymaganiami, projektami, kodami, specyfikacjami testów, instrukcjami uŝytkownika i, stosownie do potrzeb, innymi dodatkowymi elementami. Dalsze informacje moŝna znaleźć w pozostałych normach 13, 14 12 ISO/IEC 12207:1995 [11], 5.3 (rozwój) i 6.5 (walidacja) oraz ISO/IEC 12207:1995/Poprawka 1:2002 [12], F.1.3 (rozwój) i F.2.5 (walidacja);iso/iec 14598-3 [15] i ISO/IEC 14598-5 [17]. 13 ISO/IEC 12207:1995 [11], 5.5.2, 5.5.3 (modyfikacje), 6.1 i 6.2 (zarządzanie konfiguracją), oraz ISO/IEC 12207:1995/Poprawka 1:2002 [12], F.2.1 (dokumentacja) i F.2.2 (zarządzanie konfiguracją). 14 Dalsze wskazówki ogólne dotyczące ISO 9001:2000, 7.3 Projektowanie i rozwój moŝna znaleźć w następujących normach: ISO/IEC 12207:1995/Poprawka 1:2002 [12], f.1.3.4 (analiza wymagań dot. oprogramowania) i F.1.3.5 (projektowanie oprogramowania); ISO/IEC 12119:1994 [10] wskazówki dot. nabytego oprogramowania z półki ; ISO/IEC 6595:2000 [1] 16
Załącznik nr 3 Opracowanie mapy poszczególnych procesów z uwzględnieniem załoŝeń modelu semantycznego dla 7.3. 1 do 7.3.7 wskazówki dot. dokumentacji programowania i rozwoju; ISO/IEC 19761 [31], ISO/IEC 20926 [32] i ISO/IEC 20968 [33] wskazówki dot. oceny metod wielkościowych; ISO/IEC TR 14759 [18] wskazówki dot. kategoryzacji prototypów i przykłady stosowania ISO/IEC 15910 [28] proces dokumentacji uŝytkowników oprogramowania. 17
Rysunek 3. Mapa procesów. Uszczegółowienie procesów głównych projektowanie i rozwój dla organizacji wytwarzających oprogramowanie w oparciu o wymagania ISO 9001: 2000 i zalecenia ISO/IEC 9000. Dotyczy punktów 7.3..4 do 7.3.7. P -8 P-9 7.3. Projektowanie i rozwój 7.3.1 Planowanie projektowania 7.3.2 Dane wejściowe do 7.3.7 Nadzorowanie zmian i rozwoju projektowania i rozwoju w projektowaniu 4.2.4 i rozwoju 7.3.3 Dane wyjściowe z projektowania i rozwoju K20 7.5.3 K1 K2 K3 K4 K5 7.3.1 P-3 7.3.1 4.2.4 P-1 P-2 7.3.4 7.3.5 7.3.6 Przegląd projektowania i rozwoju Weryfikacja projektowania i rozwoju Walidacja projektowania i rozwoju 8.3 4.2.4 a h 4.2.4 P-4 7.3.6.1 Walidacja P-5 P-6 P-7 7.3.6.2 Testowanie a 1 b c K10 K11 K12 K13 K14 7.3.1 4.2.4 K15 K16 K17 K18 d Źródło : Opracowanie własne. Uwaga: wyjaśnienie oznaczeń zawiera załącznik nr 1.
Załącznik nr 4 : opracowanie potencjalnych obszarów decyzyjnych dla poszczególnych procesów SZJ dla punktów 7.3.1 do 7.3.7 Opracowana mapa procesów dla procesu projektowania i rozwoju spełniająca wymagania normy ISO 9001:2000 i zalecenia podane w ISO/IEC 90003 posłuŝy do dokonania lokalizacji wiedzy w OWO stosującej SZJ. Jest to moŝliwe pod warunkiem: a) wcześniejszego zdefiniowania potencjalnych decyzji, które powinny być podejmowane przez zespół realizatorów 15 b) przyjęcia hierarchii poziomów opisu wiedzy, która pozwoli dotrzeć do atomu wiedzy, wiedzy elementarnej, fragmentu wiedzy, itd. Tak jak to proponuje K.Wiig ( za J.Gołuchowski: Technologie informatyczne w zarządzaniu wiedzą w organizacji, Wydawnictwo AE Katowice 2005, s. 31 ) PoniŜsza tabela dla wybranych elementów modelu podaje potencjalne decyzje. Pozwolą one opracować hierarchię poziomów wiedzy. Tak powstała hierarchia poziomów wiedzy pozwoli na lokalizację wiedzy. w OWO i stosującej SZJ Struktura procesów związanych z projektowaniem i rozwojem dla przypomnienia zawiera następujące elementy : 1) Planowanie projektowania i rozwoju 7.3.1 - planowanie projektowania i rozwoju 7.3.1.1 - przegląd, weryfikacja i walidacja - 7.3.1.2 - zakres odpowiedzialności i uprawnień 7.3.1.3 - interfejsy 7.3.1.4 2) Dane wejściowe do projektowania i rozwoju 7.3.2 3) Dane wyjściowe z projektowania i rozwoju 7.3.3 4) Przegląd projektowania i rozwoju 7.3.4 5) Weryfikacja projektowania i rozwoju- 7.3.5 6) Walidacja projektowania i rozwoju 7.3.6 7) Nadzorowanie zmian w projektowaniu i rozwoju 7.3.7 PoniŜsze tabele dla wybranych elementów modelu podają lokalizują wiedzę w OWO, która stosuje SZJ. potencjalne decyzje. One 15 J. Kisielnicki: System pozyskiwania i zarządzania wiedzą we współczesnych organizacjach, [w:] Zarządzanie wiedzą we współczesnych organizacjach, Oficyna Wydawnicza WyŜszej Szkoły Handlu i Prawa im. R. Łazarskiego, Warszawa 2003, s.18. 19
Tab.1 Potencjalne decyzje lokalizujące wiedzę w OWO dla planowania i projektowania rozwoju Lp. Element normy ISO Potencjalne decyzje lokalizujące wiedzę w OWO 1 Postulat 1 i 2 ( 7.3.1 ) Określenie etapów projektowania i rozwoju 2 j.w. Określenie dla kaŝdego etapu przeglądu, weryfikacji i walidacji 3 j.w. Określenie odpowiedzialności i uprawnień projektowania i rozwoju 4 Postulat 3 ( 7.3.1 ) Określenie powiązań pomiędzy róŝnymi grupami biorącymi udział w projektowaniu i rozwoju 5 j.w. Określenie zasad zapewniających skuteczną komunikacje pomiędzy róŝnymi grupami biorącymi udział w projektowaniu i rozwoju 6 j.w. Wyraźne wyznaczenie odpowiedzialności pomiędzy róŝnymi grupami biorącymi udział w projektowaniu i rozwoju 7 Postulat 4 ( 7.3.1 ) Określenie sposobu aktualizacji danych wyjściowych z postępu prac w projektowaniu i rozwoju 8. Kwestia 1 ( 7.3.1.1 ) Sposoby dopilnowania przez organizację, aby wyroby były rozwijane z określonymi wymaganiami oraz zgodnie z planowaniem projektowania i rozwoju i/lub planowania jakości 9. Kwestia 3 ( 7.3.1.1 ) Określenie działań z zakresu planowania na potrzeby kontroli produktów i świadczenia usług 10 Kwestia 4 ( 7.3.1.1 ) Określenie organizacji zasobów projektu ( w tym strukturę zespołu, zakresy obowiązków, stosowane zasoby materiałowe, korzystanie z dostawców ) 11 Kwestia 5 ( 7.3.1.1 ) Określenie działań z zakresu interfejsów organizacyjnych i technicznych miedzy poszczególnymi jednostkami lub grupami ( zespoły projektowe, dostawcy, partnerzy, uŝytkownicy, przedstawiciele klientów, przedstawiciele ds. zapewnienia jakości ) 12 Kwestia 6( 7.3.1.1 ) Określenie działań z zakresu analizy moŝliwego ryzyka, zaleŝności i problemów związanych z projektowaniem i rozwojem 13 Kwestia 7 ( 7.3.1.1 ) Określenie harmonogramu, który identyfikuje co najmniej: projekt, podział obowiązków, dodatkowe zasoby i synchronizację, dodatkowe zaleŝności, punkty węzłowe harmonogramu, działania weryfikacyjne i walidacyjne 14 Kwestia 8 ( 7.3.1.1 ) Określenie działań z zakresu identyfikacji a) norm, reguł, praktyk i konwencji, metodologii, modelu cyklu Ŝycia, wymagań ustaw i przepisów [jak 7.1.2 d) i e)]; 20
b) narzędzi i technik do rozwoju, w tym równieŝ kwalifikacji narzędzi i technik i konfiguracji ich elementów sterujących; c) urządzeń, sprzętu i oprogramowania uŝywanego do rozwoju; d) konfiguracji praktyk zarządzania [jak w punkcie 7.1.2 h)]; e) metody kontrolowania niezgodności wyrobów; f) metody nadzoru nad oprogramowaniem stosowane w celu wsparcia rozwoju; g) procedur słuŝących do archiwizacji, wykonywania rezerwowych kopii i kontroli dostępu do oprogramowania; h) metody nadzoru nad zabezpieczeniem antywirusowym; i) kontroli zabezpieczenia. 15 Kwestia 9 ( 7.3.1.1 ) Określenie planowania jakości, zarządzania ryzykiem, zarządzania konfiguracją, zarządzania dostawcami, integracji, testowania, zarządzania wydaniami, instalacji, szkolenia, migracji, konserwacji, ponownego wykorzystania, komunikacji i pomiaru 16 Kwestia 10 ( 7.3.1.1 ) Określenie działań z zakresu nadzoru nad dokumentacją ( w tym archiwum dokumentów i dystrybucja ) 17 Postulat 5 ( 7.3.1.1 ) Określenie okresowych przeglądów planowania oraz wprowadzanie zmian w planach 18 Kwestia 15 ( 7.3.1.4) Określenie granic odpowiedzialności w przypadku kaŝdej części wyrobu oraz określenie sposobu przesyłania informacji technicznych pomiędzy stronami 19 Kwestia 16( 7.3.1.4 ) Określenie w trakcie definiowania interfejsów- innych podmiotów ( poza klientem i organizacją ) zainteresowanych działaniami z zakresu projektowania i rozwoju, instalacji, eksploatacji, konserwacji i szkolenia Tab. 2 Potencjalne decyzje lokalizujące wiedzę w OWO dla Dane wejściowe do projektowania i rozwoju 7.3.2. Dane wyjściowe z projektowania i rozwoju- 7.3.3 ) Lp. Element normy ISO Potencjalne decyzje lokalizujące wiedzę w OWO 1 Postulat 1 (7.3.2 ) Określenie danych wejściowych do projektowania i rozwoju ( z uwzględnieniem kwesti 2) 2 Postulat 2 ( 7.3.2 ) Określenie sposobu przeglądu danych wejściowych pod katem ich adekwatności ( z uwzględnieniem kwestii 3 ) 3 Postulat 4, Kwestia 4 Określenie zakresu oraz sposobu dokumentowania danych (7.3.3) wyjściowych z projektowania i rozwoju 4 Kwestia 6 ( 7.3.3) Określenie sposobu prezentacji danych wyjściowych z projektowania i rozwoju 5 Kwestia 8 ( 7.3.3) Określenie kryteriów przyjęcia danych wyjściowych z 21
projektowania i rozwoju w celu wykazania, Ŝe dane wejściowe do kaŝdego etapu projektowania i rozwoju znalazły prawidłowe odzwierciedlenie w danych wejściowych Tabela 3 Potencjalne decyzje lokalizujące wiedzę w OWO dla przeglądu, weryfikacji, walidacji, nadzorowania zmian w projektowaniu i rozwoju planowania i projektowania rozwoju ( Dane wejściowe do projektowania i rozwoju 7.3.2. Dane wyjściowe z projektowania i rozwoju-7.3.3 ) Lp. Element modelu Potencjalne decyzje lokalizujące wiedzę w OWO 1. Postulat 1 ( 7.3.4 ) Określenie etapów na których naleŝy przeprowadzić systematyczne przeglądy 2. Postulat 2 ( 7.3.4 ) Określenie zapisów z wyników przeglądów i wszelkich niezbędnych działań Określenie słuŝb związanych z etapami projektowania i rozwoju, które podlegają przeglądom 3. Kwestia 1 ( 7.3.4 ) Określenie stopnia sformalizowania działań związanych z procesami przeglądu 4. Kwestia 2 ( 7.3.4) Określenie procedur postępowania w przypadku wad procesów i wyrobów lub niezgodności stwierdzonych w trakcie tych działań 5. Kwestia 3 ( 7.3.4 ) Określenie kryteriów branych pod uwagę w trakcie przeglądów projektowania i rozwoju 6 Kwestia 4 ( 7.3.4 ) Określenie elementów przeglądu projektowania i rozwoju do uwzględnienia w trakcie wykonywania 7 Postulat 3 ( 7.3.5) Określenie sposobu zapewnienia, Ŝe dane wyjściowe z projektowania i rozwoju spełniły wymagania określone w danych wejściowych 8 Kwestia 8, 9 ( 7.3.5 ) Określenie sposobu przeprowadzenia weryfikacji projektowania i rozwoju w zaleŝności od skali, złoŝoności, znaczeniem oprogramowania 9 Kwestia 10 ( 7.3.6.1) Określenie sposobów uzyskania uzasadnionego przeświadczenia, Ŝe oprogramowanie spełnia wymagania robocze 10 Kwestia 11 ( 7.3.6.1 ) Określenie sposobu walidacji, gdy nie jest ona wykonalna w warunkach eksploatacji 11 Kwestia 14 ( 7.3.6.1 ) Określenie badań i analiz zwiększających przeświadczenie, Ŝe wyrób będzie działał prawidłowo w nietestowalnych warunkach 12 Kwestia 15 ( 7.3.6.2) Określenie podejścia do testowania pozwalającego na przeprowadzenie walidacji 13 Kwestia 15, 16 ( 7.3.6.2) Ustalenie planów testowania 14 Kwestia 17 ( 7.3.6.2) Wybór narzędzi i środowiska do testowania 15 Postulat 10 ( 7.3.7 ) Określenie oceny wpływu zmian na części składowe i juŝ dostarczony wyrób 22
Źródło: Opracowanie własne. Załącznik 5: Zdefiniowanie elementów wiedzy SZW dla wybranego obszaru decyzyjnego dotyczącego punktów normy 7.3.1 23
Hierarchia poziomów opisu wiedzy składa się z następujących elementów struktury wiedzy: a) dziedzina wiedzy b) region wiedzy c) segment wiedzy d) element wiedzy e) fragment wiedzy f) atom wiedzy Tab. 4 Hierarchia wiedzy w zakresie wybranych obszarów decyzyjnych Obszary decyzyjne Hierarchia poziomów wiedzy Dziedzina wiedzy Region wiedzy Segment wiedzy Element wiedzy Określenie etapów P+R Projektowanie i rozwój systemów informatycznych Procesy podstawowe Sposoby definiowania etapów P+R Konkretne etapy wg obranego sposobu Określenie dla kaŝdego etapu przeglądu, weryfikacji i walidacji Projektowanie i rozwój systemów informatycznych Procesy podstawowe MoŜliwy zakres działań podejmowanych w trakcie przeglądu, weryfikacji i walidacji Faktyczne działania podejmowane podczas przeglądu, weryfikacji i walidacji dla konkretnego etapu Określenie odpowiedzialności i uprawnień P+R Projektowanie i rozwój systemów informatycznych Określenie powiązań pomiędzy róŝnymi grupami biorącymi udział w P+R Projektowanie i rozwój systemów informatycznych Procesy Procesy podstawowe podstawowe MoŜliwy zakres odpowiedzialności i uprawnień odniesiony do P+R Faktyczna odpowiedzialność i uprawnienia odniesiona do etapów, działań weryfikacyjnych i walidacyjnych MoŜliwe powiązania między grupami pracowników biorącymi udział w P+R Faktyczne powiązania między grupami pracowników po uwzględnieniu realizowanego etapu P+R, zdefiniowanych dla niego 24
Fragment wiedzy Atom wiedzy Elementy do uwzględnienia na kaŝdym etapie, aby moŝna uznać go za skończony kompletny) Wartości przyjmowane przez elementy wchodzące w skład kaŝdego etapu Stosowane techniki dla faktycznie podejmowanych działań w ramach przeglądu, weryfikacji i walidacji Rezultat stosowanych technik w zakresie przeglądu, weryfikacji i walidacji Przydzielenie odpowiedzialności poszczególnym grupom pracowników Odpowiedzialność i uprawnienia przypisane jednemu pracownikowi przeglądu, weryfikacji i walidacji oraz poczynionych uzgodnień co do odpowiedzialności i uprawnień Określenie powiązań pomiędzy grupami pracowników Powiązania pomiędzy dwoma pracownikami z róŝnych grup 25