Standardy związane z zapewnieniem jakości zostały opracowane przez International Organisation for Standardisation (ISO). Normy te są znane jako normy serii ISO 9000 i dotyczą zapewnienia jakości we wszelakich obszarach działalności. W praktyce system zapewnienia jakości oparty na normach serii ISO 9000 opiera się na zestawach procedur, opisujących procesy, w których uczestniczą osoby o ściśle sprecyzowanych odpowiedzialnościach i uprawnieniach. Żeby wykazać się zgodnością ze standardami ISO należy przedstawić zestaw odpowiednich procedur regulujących działanie organizacji oraz wykazać, że procedury te są rzeczywiście stosowane.

Produkcja oprogramowania jest specyficznym rodzajem działalności. Ogólne normy muszą być zweryfikowane i dostosowane, żeby mogły spełniać swoją rolę przy tworzeniu systemów IT. W związku z tym powstał ciąg norm związanych z zarządzaniem jakością, przeznaczonych wyłącznie dla informatyki.

Pierwszym dokumentem z tej serii są wytyczne do stosowania norm ISO 9000 w trakcie produkcji i obsługi oprogramowania – dokument oznaczony jako ISO 9000-3 (dokument ten będziemy dla prostoty także nazywać „normą”, chociaż oficjalnie nosi on tytuł „zalecenia do stosowania normy”). Uzupełnieniem normy ISO 9000-3 jest norma ISO/IEC 12207 opisująca zestaw specyficznych czynności związanych z cyklem życia oprogramowania. Powstała także norma opisująca charakterystyki jakie powinno mieć dobre oprogramowanie (ISO 9126). Z kolei norma ISO 15504 SPICE (Software Process Improvement and Capability Determination) opisuje szczegółowo czynności które należy wykonać przy ocenianiu czy proces produkcji oprogramowania przebiega poprawnie.

Równolegle do norm ISO w Software Engineering Institute (Carnegie Mellon University) opracowano model CMM (Capability Maturity Model) opisujący zestaw bardzo konkretnych aktywności, które muszą być realizowane przez firmy zajmujące się produkcją oprogramowania. Model ten jest bardzo technologiczny, software’owy i nie jest obciążony ogólnymi rozważaniami na temat jakości, nie związanymi z informatyką.

Przykładem szczególnego nastawienia na jakość są techniki specjalne opisane w ostatnim podrozdziale. Technologia Czystego Pokoju opiera się na wykorzystaniu technik związanych z formalnym podejściem do projektowania, dowodzeniem poprawności oprogramowania oraz statystyczną analizą sposobów wykorzystania systemu jako podstawą testowania. Techniki poka-yoke są nastawione na przeciwdziałanie błędom i ich szybkie usuwanie.

Kilka uwag praktycznych

Najważniejsi są ludzie. Jeżeli do projektu zatrudnieni ludzie o niskich kwalifikacjach, trudno będzie poprzez techniki zarządzania jakością uzyskać poprawne efekty pracy. Szkolenia mogą tylko w niewielkim stopniu poprawić sposób pracy osób, które nie mają predyspozycji do wykonywania swoich funkcji.

Każdy produkt musi być sprawdzony. Trzeba się starać wyłapywać problemy najwcześniej jak tylko można. Szacuje się, że koszt usuwania błędów rozkłada się jak 1 : 10 : 100. Koszt usunięcia błędu w fazie analizy i projektowania to jedna jednostka. Koszt usunięcia tego samego błędu w fazie testowania oprogramowania to 10 jednostek. Jeżeli błąd zostanie zidentyfikowany w trakcie eksploatacji systemu, możemy się spodziewać, że jego usunięcie (przeprojektowanie, programowanie, ponowna instalacja aplikacji) będzie sto razy większy niż koszt naprawy po wykryciu go we wstępnych fazach produkcji oprogramowania.

Zadaniem wewnętrznej kontroli jest poprawienie jakości, a nie walka z resztą zespołu. Osoby zajmujące się na potrzeby zespołu projektowego kontrolą jakości muszą wiedzieć, jaka jest ich właściwa rola. Dlatego zawsze w protokołach wewnętrznej kontroli jakości umieszczałem pole: „Opis problemu. Propozycje naprawy”. Ponadto czasami konieczna jest świadoma, dla dobra projektu, akceptacja mniejszych lub większych usterek. Są takie błędy, których istnienie nie może blokować postępu całego projektu. Dlatego kontrolerzy jakości nie mogą być ostateczną instancją decydującą o akceptacji produktów. Ich – bardzo ważna!!! – opinia jest jedną z podstaw do podjęcia decyzji o akceptacji wyników prac. Tyle będzie jakości, ile budżetu i czasu przeznaczono na jakość.

Prawdziwa jakość wymyka się spod kontroli formalnej. Jakość formalna produktu, czyli takie cechy jak zgodność ze standardami, spójność z innymi produktami i półproduktami, wewnętrzna spójność produktu (dokumentu) czy ich zrozumiałość to tylko część cech dobrych produktów. Ale poza tym oprogramowanie musi być dobre, sprawne, użyteczne, poprawnie skonstruowane (nie definiujmy tych pojęć, każdy ma swoją intuicję). Dlatego osoby zajmujące się kontrolą jakości powinny mieć sporo wiedzy technicznej. Najlepszym rozwiązaniem zawsze jest wykonywanie kontroli jakości przez osoby mające techniczne doświadczenie w obszarze weryfikowanego dokumentu. I tu proponuję spojrzeć na mój życiorys zawodowy :-)

Przeglądy produktów. Bierzemy produkt i dajemy go osobie nie będącej jego autorem. Osoba ta dokładnie (lepiej: bardzo dokładnie) zapoznaje się z produktem i przygotowuje pisemną opinię. Opinia jest dostarczana autorowi. Autor dostaje odpowiedni czas na zapoznanie się z opinią. Odbywa się spotkanie, na którym opiniodawca i autor konfrontują swoje opinie. Taką procedurę nazywamy przeglądem produktu. Przegląd może być dla autora bolesny, ale w jego ramach zwykle znajduje się wiele rozwiązań zidentyfikowanych problemów. Zalecam wykonywanie przeglądów wszystkich najważniejszych produktów projektu!

Podstawowy zestaw procedur jakościowych to odbiór produktów, zarządzanie zmianami, zarządzanie problemami i wewnętrzna kontrola jakości. Standardy jakości nakazują opracowanie wielu procedur. Wśród nich znajdują się ważne i ważniejsze. To co musi być ustalone pomiędzy wykonawcą i klientem to właśnie trzy pierwsze wymienione procedury. Bez sformalizowanej procedury odbioru jesteśmy narażeni na ponowne wykonywanie prac; klient może powiedzieć, że „to można jeszcze ulepszyć” albo „przecież nie o to mi chodziło”. Procedura odbioru produktu ze wskazaniem odpowiedzialnych osób, trybu i czasu akceptacji chroni nas przed wieloma komplikacjami. Procedura zarządzania zmianami musi być jednym środkiem wprowadzania modyfikacji do wszystkich planów. To też jest obrona przed niekontrolowanym rozpełzaniem się projektu. W projektach często powstają kwestie co do których dwie strony mają różne opinie (problemy). Procedura zarządzania takimi kwestiami powinna wskazywać osoby upoważnione do podejmowania odpowiednich decyzji – np. w zależności od rozmiaru wpływu konsekwencji decyzji na realizację projektu. O procedurze wewnętrznej kontroli jakości powiedziałem kilka słów wyżej.

Norma ISO 9000-3

Norma opisuje działania, które muszą wykonać producent oprogramowania (zwany dostawcą) i nabywca w trakcie całego cyklu życia systemu. W niniejszym opracowaniu przedstawimy i skomentujemy niektóre zapisy znajdujące się w tej normie.

Norma stara się uporządkować odpowiedzialności nabywcy w trakcie produkcji oprogramowania. Jeśli oprogramowanie jest produkowane na zamówienie, to nabywca powinien wskazać jedną osobę, która będzie odpowiedzialna m. in. za (punkt 4.1.2):

· Określenie wymagań,

· Odpowiadanie na pytania producenta,

· Zatwierdzanie propozycji producenta.

Do realizacji tych zadań należy wyznaczyć osobę mającą właściwe uprawnienia. Praktyka wskazuje, że osobą taką powinien być ktoś ze ścisłego zarządu firmy lub jednostki organizacyjnej dla której przeznaczony jest produkowany system. Nie powinien to być jednak jej szef – osoby te zwykle nie mają dostatecznie wiele czasu, żeby móc na bieżąco współpracować z producentem. Odpowiedzialność przypisana jednej osobie powinna zagwarantować, że wymagania będą spójne. Zapisy o konieczności odpowiadania na pytania producenta oraz zatwierdzania jego propozycji mają na celu zagwarantowanie, że producent uzyska właściwą wiedzę o dziedzinie działania systemu oraz że proces produkcji nie będzie wstrzymywany przez oczekiwanie na reakcję nabywcy.

Umowa, na podstawie której realizowany jest kontrakt powinna zawierać m. in. (punkt 5.1.2):

Kryteria odbioru,
Sposoby wprowadzania zmian w wymaganiach po podpisaniu umowy,
Sposoby rozwiązywania problemów wykrytych po odbiorze,
Określenie roli nabywcy w trakcie tworzenia specyfikacji, instalowania i odbioru,
Specyfikację sprzętu i oprogramowania dostarczanego przez nabywcę.

Jednym z zasadniczych problemów w realizacji projektów informatycznych jest zmienność wymagań. Z drugiego z zacytowanych zapisów wynika, że częścią umowy powinna być procedura zarządzania zmianami w wymaganiach. Kluczowym problemem, który należy rozwiązać przy definiowaniu takiej procedury jest ustalenie zakresu zmian, które mogą być wprowadzone do systemu przez osoby biorące udział w produkcji (kierownik projektu, sponsor) oraz sposoby rozstrzygania sporów, jeśli nabywca i producent nie mogą ustalić wspólnego stanowiska dotyczącego napotkanego problemu.

Norma zaleca (punkt 5.3.1), „aby przed przystąpieniem do opracowywania oprogramowania, dostawca posiadał kompletny i jednoznaczny zestaw wymagań funkcjonalnych.” Zapis ten był wielokrotnie poddawany krytyce. Opublikowane przez IBM badania (W. Gibbs, Software’s Chronic Crises, Scientific American Magazine, September 1994) wykazały, że 88% dużych systemów, które zostały wykonane dokładnie według wcześniej przygotowanych specyfikacji nie nadawało się do użytku!

Podstawowym dokumentem związanym z zarządzaniem jakością jest według normy ISO 9000-3 plan zarządzania jakością (punkt 5.5.2). Plan ten powinien zawierać:

Mierzalne cele jakościowe,
Kryteria dla wejść i wyjść z każdego etapu pracy,
Opis testów, weryfikacji i sposobów ich zatwierdzania,
Plany związane z testami i weryfikacjami oraz wskazanie osób upoważnionych do ich zatwierdzania,
Określenie odpowiedzialności za działania związane z jakością takie jak testy i przeglądy, zarządzanie konfiguracją, zarządzanie zmianami, postępowanie z wyrobami nie spełniającymi wymagań.

W praktyce mierzalne cele jakościowe to liczba błędów wykrytych w czasie testowania, czas bezawaryjnej pracy systemu, czas ponownego uruchomienia systemu, liczba możliwych awarii systemu w jednostce czasu. Wymagania takie mogą się także odnosić do liczby problemów wykrytych w czasie wykonywania testów jednostkowych czy testów integracyjnych systemu.

Norma ISO 9126

Jakie oprogramowanie można nazwać dobrym oprogramowaniem? Na to pytanie odpowiada norma ISO 9126. Według tego dokumentu istnieje sześć podstawowych cech charakteryzujących dobre produkty software’owe. Są to:

Funkcjonalność,
Niezawodność,
Użyteczność,
Efektywność,
Pielęgnowalność,
Przenaszalność.

Funkcjonalność

Po pierwsze każdy system powinien robić dokładnie to, co jest użytkownikowi potrzebne. W sformułowaniu tym nie ma odwołania do pojęć typu „wymagania” czy „specyfikacja”. Wymagania i specyfikacja są półproduktami („artefaktami”) wytworzonymi w trakcie pracy nad systemem i mogą być obarczone błędami wynikającymi zarówno z zachowań klienta jak i wytwórców oprogramowania. Zadaniem połączonego zespołu jest przewidzenie potrzeb przyszłego użytkownika, dla którego ewentualne niedostatki w pracy wytwórców nie będą wytłumaczeniem złego działania systemu. I dlatego pojęcie „funkcjonalność” nie odwołuje się do tego co się udało albo nie udało spisać w fazie analizy.

Niezawodność

System nie tylko musi mieć zaprogramowane potrzebne funkcje. Musi istnieć gwarancja, że funkcje te będą realizowane odpowiednio sprawnie. Po pierwsze system nie może mieć błędów. Wywołanie każdej funkcji musi się zakończyć pomyślnie i funkcja musi dać spodziewane wyniki. Miarami służącymi do oceny niezawodności są liczba stwierdzonych błędów, średni czas niezawodnej pracy systemu. Dobrze jest, jeżeli system sam potrafi bronić się przed błędami, jeśli zaistnieją. Czasami, szczególnie w systemach, które muszą być szczególnie niezawodne, w celu wykrycia błędów stosuje się techniki oparte na redundancji. Po stwierdzeniu, że błąd wystąpił powinna nastąpić naprawa systemu. Istotną charakterystyką związaną z niezawodnością jest czas naprawy błędu (naprawa funkcji i błędów w danych spowodowanych awarią).

Użyteczność

Użyteczność są to charakterystyki związane z możliwościami i łatwością wykorzystania systemu. Sposób wykorzystania funkcji musi być łatwy do opanowania. System podręczników, helpów i tutoriali musi być dostosowany do wiedzy użytkownika. Nawigacja pomiędzy formularzami ekranowymi powinna być przejrzysta i zrozumiała. Wszystkie dane potrzebne do wykonywania funkcji powinny być wprowadzane do systemu tylko raz. Użyteczność systemu to także możliwość sprawnego administrowania nim.

Efektywność

Efektywność jest to stosunek wydajności oprogramowania do wykorzystanych zasobów. Zasoby są dzielone na czas oraz inne zasoby. System musi szybko udzielać odpowiedzi na zadane mu pytania; funkcje muszą być realizowane szybko. Oczywiście pojęcie „szybkość” jest względne i jest specyficzne dla każdej funkcjonalności. W ocenie pozostałych zasobów – innych produktów programistycznych, sprzętu, materiału, personelu – istotne są dwa czynniki: wolumen zasobów oraz czas ich zaangażowania.

Pielęgnowalność

Zgodnie z pierwszym prawem ewolucji systemów „używany system jest poddawany ciągłym zmianom do czasu gdy bardziej ekonomiczne okaże się zastąpienie go nowym lub zrestrukturyzowanym systemem” (L. Belady and M. Lehman, Program Evolution Processes of Software Change, Academic Press, London, UK, 1985.). Czyli każdy system musi być wielokrotnie modyfikowany. W trakcie eksploatacji do systemu wprowadzane są poprawki mające na celu usunięcie stwierdzonych błędów. Wprowadzane są także modyfikacje mające na celą efektywniejszą realizację funkcji. Zmiany mogą być konieczne w wyniku wprowadzenia zmian w środowisku systemu – np. zamieniony system zewnętrzny wymaga innych interfejsów. Pielęgnowalność oznacza możliwość łatwego wprowadzania modyfikacji. Po pierwsze w przypadku zaistnienia potrzeby zmiany łatwe musi być znalezienie tego fragmentu systemu, który ma być zmieniony (aplikacja, moduł, fragment modułu). Po drugie wprowadzanie zmian powinno wpływać na jak najmniejszą liczbę jednostek programowych (system musi być napisany modularnie). Po trzecie praca włożona w modyfikację powinna być jak najmniejsza. I w końcu po czwarte – łatwe powinno być przetestowanie skutków wprowadzenia zmiany (w szczególności przetestowanie całego systemu w poszukiwaniu niezamierzonych efektów zmiany).

Istnieje opinia, że podstawową charakterystyką systemu jest właśnie pielęgnowalność; w pewnym sensie jest ona ważniejsza niż funkcjonalność i niezawodność. Według tej opinii błędy istnieją we wszystkich systemach. A jakość budowy systemu poznaje się po tym jak łatwo można znaleźć przyczynę błędu i zaimplementować nową funkcjonalność.

Przenaszalność

Przenaszalność jest to możliwość wykorzystania oprogramowania w wielu środowiskach, w szczególności w innych niż to, dla którego zostało początkowo wyprodukowane. Dobrze jest, jeżeli system ma wbudowane mechanizmy ułatwiające automatyczną produkcję wersji dla różnych środowisk (np. warunkowa kompilacja). Elementem przenaszalności jest łatwość instalacji systemu. Niewątpliwie przenaszalność sprzyja zgodność z ogólnie przyjętymi standardami. Jeśli oprogramowanie trzyma się np. standardów interfejsu, to potencjalni użytkownicy (to też element środowiska pracy systemu) szybciej nauczą się korzystania z niego. O potencjalnej przenaszalności systemu świadczy wreszcie jego uniwersalna funkcjonalność – im więcej ogólnie potrzebnych funkcji system będzie realizował, tym większe jest prawdopodobieństwo, że znajdzie się na niego wielu chętnych użytkowników.

Norma ISO/IEC 12207

Norma ISO/IEC 12207 opisuje procesy cyklu życia oprogramowania. Według tej normy procesy te dzielą się na trzy klasy:

Podstawowe,
Wspomagające,
Organizacyjne

Każdy z procesów jest rozpisany na czynności. Zwykle czynności w każdym procesie można podzielić na przygotowawcze (planistyczne) i wykonawcze. Standard określa jakie czynności należy wykonać, ale nie zawęża ich stosowania do określonych metod czy technologii.

Norma ISO 12207 może być stosowana w części lub w całości. Firma, która wyłącznie produkuje i wykorzystuje systemy, może zastosować wymagania dotyczące naboru i działania oprogramowania, nie musi stosować standardów związanych ze wspomaganiem produkcji (np. dokumentowanie, zarządzanie jakością czy wspólne przeglądy).

Obszarami zastosowania normy mogą być organizacje lub poszczególne projekty. Praktyka pokazuje, że najpierw powstają standardy przeznaczone do stosowania w określonych projektach, a później są one rozszerzane na całą firmę.

Procesy podstawowe

Nabór

Proces naboru opisuje czynności związane z kontraktowym nabyciem (zakupem, uzyskaniem licencji) oprogramowania. Pierwszą czynnością procesu jest jego inicjacja, czyli zdefiniowanie potrzeby wykorzystania oprogramowania. Po zdefiniowaniu takiej potrzeby należy przygotować zapytanie ofertowe. Następnie należy przygotować kontrakt, zmodyfikować go w wyniku negocjacji z klientem i podpisać. Po podpisaniu kontraktu należy monitorować jego realizację. Realizacja kontraktu kończy się jego zatwierdzeniem i zakończeniem.

Dostarczanie

Proces dostarczania jest rozpoczynany w wyniku podjęcia decyzji o próbie realizacji kontraktu, którego zapytanie ofertowe (pisemne lub w innej formie) jest dostępne dla firmy dostarczającej oprogramowanie. Inną możliwością rozpoczęcia procesu dostarczania oprogramowania jest podpisanie kontraktu na świadczenie usług software’owych (np. produkcja, obsługa, pielęgnacja systemu). W procesie wyróżniona jest czynność podpisania kontraktu. W ramach planowania określane są procedury i zasoby konieczne do realizacji procesu. Wykonanie kontraktu podlega monitorowaniu i zarządzaniu. Kontrakt musi być jawnie zakończony.

Produkcja

Najbardziej rozbudowany proces określający wymagania na produkcję produktu software’owego. Przez produkcję jest rozumiane zarówno opracowanie systemu od początku jak i jego modyfikacje. Wstępną czynnością procesu jest dokładne zdefiniowanie jego czynności i zależności pomiędzy tymi czynnościami. Norma wyróżnia następujące czynności:

Analiza wymagań systemowych,
Projektowanie systemu,
Analiza wymagań software’owych,
Projektowanie architekturalne,
Projektowanie szczegółowe,
Kodowanie i testowanie oprogramowania,
Integracja oprogramowania,
Testy systemu software’owego,
Integracja systemu,
Testy systemu,
Instalacja oprogramowania,
Nadzór akceptacyjny oprogramowania.

Kolejność wymienienia czynności nie przesądza o kolejności ich wykonania w rzeczywistości – standard może być stosowany do różnych modeli produkcji oprogramowania (model kaskadowy, spiralny czy kontrolowanych iteracji).

Działanie

Czynności związane z wykorzystaniem systemu. Pierwszą czynnością powinno być określenie czynności związanych z wykorzystaniem systemu. Do działania systemu zaliczane jest testowanie w warunkach rzeczywistych. Pozostałymi czynnościami są standardowe prace związane z utrzymaniem systemu (np. zarządzanie użytkownikami, zabezpieczanie i odtwarzanie danych) oraz wsparcie użytkownika.

Pielęgnacja

Celem uruchomienia procesu pielęgnacji może być

naprawienie błędu,
zmiana funkcjonalności,
usprawnienie sposobu realizacji funkcji oraz
zapobieganie błędom.

Proces pielęgnacji musi zachowywać integralność oprogramowania.

Czynnością wstępną jest organizacja i wdrożenie procesu pielęgnacji. Następnie należy przeanalizować przyczyny, które doprowadziły do podjęcia decyzji o modyfikacji oraz możliwości wykonania tej modyfikacji. Po wykonaniu modyfikacji należy zaakceptować jej wyniki – na przykład poprzez wykonanie testów. Poprawiony system musi być wdrożony. Elementem procesu pielęgnacji jest wycofanie systemu z eksploatacji.

Procesy wspomagające

Procesy wspomagające to te, które pomagają w realizacji procesów podstawowych.

Dokumentowanie

Zapisywanie informacji wytworzonych w innych procesach cyklu życia systemu. Większa część dokumentacji jest produkowana bezpośrednio przez osoby generujące odpowiednie informacje. Czynnością wstępną jest jak zwykle szczegółowe opracowanie czynności związanych z dokumentowaniem. Czynnościami tymi powinny być zaprojektowanie i wytworzenie dokumentacji, powielenie i dystrybucja oraz pielęgnacja.

Zarządzanie konfiguracją

Zarządzanie konfiguracją obejmuje wszystkie czynności związane ze zdefiniowaniem zestawu jednostek (obiektów), które mają podlegać kontroli wersji, z kontrolą statusu tych obiektów, z zarządzaniem zmianami w jednostkach i ich statusach, z tworzeniem wersji bazowych (spójnych, wyróżnionych zestawów obiektów tworzących system) oraz wydań systemu (wersji bazowych wypuszczanych poza zespół produkcyjny). Czynność wstępna to szczegółowe zaprojektowanie procesu zarządzania konfiguracją, który musi być dostosowany do specyfiki projektu (firmy). Następnie należy zidentyfikować obiekty podlegające zarządzaniu konfiguracją. Konfiguracja powinna być zarządzana – w szczególności powinien istnieć system nadawania oznaczeń, udostępniania i usuwania wersji jednostek. Każda jednostka w każdej konfiguracji musi mieć nadzorowany status. Powinien istnieć proces oceny konfiguracji. Ostatnią czynnością w procesie zarządzania konfiguracją jest zarządzanie wydaniami systemu oraz ich dostarczanie.

Zarządzanie jakością

Zarządzanie jakością jest to niezależne (od właściciela procesu) sprawdzenie zgodności produktu i procesu z przyjętymi wymaganiami – zarówno na produkt jak i na jego sposób produkcji (proces). Szczegółowe planowanie zarządzania jakością jest standardową czynnością. Ponadto w procesie zarządzania jakością powinny występować ocena produktu, ocena procesu oraz ocena systemu zapewnienia jakości.

Weryfikacja

Weryfikacja jest to sprawdzenie, czy proces, produkt (półprodukt) lub usługa, wymagania, projekt, kod dokumentacja lub inne wytwory spełniają postawione im wcześniej wymagania. Weryfikacja może być wykonana przez osoby z zespołu realizującego projekt lub przez osoby spoza tego zespołu – mamy wtedy do czynienia z weryfikacją niezależną.

Walidacja

Walidacja jest to sprawdzenie czy system nadaje się do wykorzystania. Zwykle walidacja odbywa się poprzez testy systemu oraz testowanie w warunkach rzeczywistych. Istniejąca dokumentacja nie musi być punktem odniesienia dla walidacji. Zasadniczym punktem odniesienia są rzeczywiste wymagania użytkownika, które zostały lub nie zostały umieszczone w istniejącej dokumentacji.

Walidacja może być, podobnie jak weryfikacja, niezależna.

Wspólne przeglądy

Wspólny przegląd jest to proces oceny produktu, w który zaangażowane są dwie strony: wykonawca i opiniodawca. Podmioty biorące udział we wspólnym przeglądzie mają równe prawa. We wspólnych przeglądach mogą uczestniczyć osoby wyłącznie ze strony producenta albo osoby z obydwu stron: zamawiającego i producenta. Wspólne przeglądy mogą dotyczyć produktów (poziom techniczny) i procesów (poziom zarządczy).

Audit

Audit jest to ocena produktu lub procesu, w którym występuje strona auditowana oraz strona auditująca. Zadaniem auditu jest sprawdzenie zgodności produktów i procesów z przyjętymi wymaganiami, normami i standardami. W porównaniu z procesem wspólnych przeglądów role stron nie są równe: występuje wyraźny podział na stronę oceniającą i ocenianą.

Rozwiązywanie problemów

Proces rozwiązywania napotkanych w trakcie realizacji problemów. Proces musi być tak określony, żeby zawsze prowadził do podjęcia ostatecznej decyzji.

Procesy organizacyjne

Procesy organizacyjne występują na poziomie projektów i całej firmy, przebiegając przez realizowane projekty.

Zarządzanie

Czynności i zadania kierownictwa związane z realizacją określonego procesu (np. naoru, dostarczenia, produkcji...) lub ich zestawu.

W skład procesu zarządzania wchodzą inicjacja i definicja zakresu (zarządzanego) procesu, planowanie, wykonanie i kontrola, przeglądy i ocena oraz zakończenie.

Infrastruktura

Infrastruktura jest to sprzęt, oprogramowanie, narzędzia, techniki, standardy i procedury, które muszą być dostępne w momencie rozpoczynania realizacji procesu. Proces infrastruktury obejmuje planowanie procesu, wskazanie elementów infrastruktury oraz konserwację wskazanych elementów infrastruktury.

Ulepszanie

Celem procesu usprawniania jest takie zmienianie procesów, aby realizująca je organizacja mogła uzyskać maksymalne korzyści z ich przyszłej realizacji.

Na ulepszanie składa się szacowanie, wyliczanie miar, kontrola i poprawianie procesów. Czynności te ogólnie dzielą się na planowanie ulepszania, ocenę procesów i usprawnianie procesów.

Szkolenie

Zasadniczym czynnikiem zapewniającym jakość procesów i produktów jest wysoki poziom wyszkolenia personelu. Proces szkolenia zawiera pozyskiwanie z zewnątrz organizacji wysoko kwalifikowanych osób oraz doskonalenie umiejętności osób zatrudnionych w projekcie lub w firmie. Szkolenia powinny się odbywać z wyprzedzeniem umożliwiającym wdrożenie przeszkolonego personelu do realizowanych zadań. Czynnościami składającymi się na szkolenia są zaplanowanie procesu, wytworzenie materiałów szkoleniowych oraz wykonanie szkoleń.

Standard ISO 15504 SPICE

Wprowadzenie

Standard ISO 15504 SPICE (Software Process Improvement and Capability Determination) opisuje szczegółowo czynności które należy wykonać przy ocenianiu czy proces produkcji oprogramowania przebiega poprawnie. Zgodnie z intencją autorów, standard „może być używany przez organizacje zaangażowane w planowanie, zarządzanie, monitorowanie, nadzorowanie i ulepszanie procesu naboru, dostarczenia, tworzenia, działania rozwoju i wspomagania działania oprogramowania.”

Standard składa się z dziewięciu części.

Część pierwsza („Pojęcia i wstępny przewodnik”) charakteryzuje standard jako całość, jego części oraz zależności pomiędzy tymi częściami.

Część druga („Model zarządzania procesem”) zawiera przede wszystkim opis czynności występujących w procesie software’owym.

Część trzecia („Proces oceny”) zawiera opis sposobu przeprowadzenia procesu oceny działalności software’owej firmy.

Część czwarta („Przewodnik do przeprowadzenia oceny”) zawiera szczegółowe wytyczne dotyczące realizacji przez zespół oceniający procesu opisanego w części czwartej.

Część piąta („Konstrukcja, wybór i używanie instrumentów i narzędzi oceny”) zawiera przede wszystkim opis sposobu konstrukcji miar i wskaźników, które mogą być wykorzystane w procesie oceny.

Część szósta („Qualification and training of assessors”) opisuje wymagania stawiane osobom dokonującym oceny procesu software’owego (doświadczenie, wykształcenie, szkolenia).

Część siódma („Przewodnik użytkowania w trakcie ulepszania procesów”) opisuje jak wykorzystać wyniki oceny w celu usprawnienia procesu software’owego.

Część ósma („Przewodnik użytkowania przy określaniu możliwości dostarczyciela [usług software’owych]”) może być wykorzystywana przy ocenie organizacji (firm) zajmujących się dostarczaniem usług. Ocenę może wykonywać firma zlecająca wykonanie usług.

Część dziewiąta to słownik pojęć występujących w standardzie.

Częściami standardu, które zawierają najwięcej ciekawych informacji są elementy poświęcone opisowi procesu software’owego (część druga) oraz opis procesu oceny (części trzecia i czwarta).

Według standardu ISO 15504 czynności (tu nazywane „praktykami”) dzielą się na czynności podstawowe i wspólne. Praktyki podstawowe to zestaw aktywności specyficznych dla danego procesu. Czynności wspólne to te, które należy wykonać żeby przeprowadzić każdy proces – na przykład planowanie.

Klasyfikacja możliwości

Zestaw i sposób wykonywania czynności charakteryzuje możliwości realizującej je organizacji. Możliwości organizacji mogą mieć sześć coraz bardziej zaawansowanych poziomów.

Poziom 0 Nie wykonywane

Podstawowe praktyki nie są wykonywane, trudno jest określić rezultaty poszczególnych czynności.

Poziom 1 Wykonywane nieformalnie

Czynności są wykonywane ale niekoniecznie są ściśle planowane. Ich wykonywanie nie musi być kontrolowane. Wydajność pracy zależy od indywidualnych umiejętności i doświadczenia wykonawców. Istnieje ogólne przeświadczenie, że poszczególne czynności powinny być wykonywane. Procesy produkują wyraźne, identyfikowalne wyniki.

Wykonywane praktyki:

1.1. Wykonywanie podstawowych praktyk

1.1.1 Wykonanie procesu

Poziom 2 Planowane i śledzone

Czynności są planowane i wykonanie planu jest nadzorowane. Sprawdzane jest, czy w celu uzyskania określonych rezultatów stosowane są odpowiednie procedury. Produkty czynności są zgodne ze standardami.

Wykonywane praktyki:

2.1 Planowanie

2.1.1 Przydzielanie zasobów

2.1.2 Przydzielanie odpowiedzialności

2.1.3 Dokumentowanie procesu

2.1.4 Dostarczanie narzędzi

2.1.5 Zapewnienie szkolenia

2.1.6 Planowanie procesu

2.2 Zdyscyplinowane wykonanie

2.2.1 Wykorzystanie planów, standardów i procedur

2.2.2 Zarządzanie konfiguracją

2.3 Weryfikacja sposobu pracy

2.3.1. Sprawdzenie zgodności procesu (ze standardami i/lub procedurami)

2.3.2 Audit produktów pracy

2.4 Nadzorowanie sposobu pracy

2.4.1 Nadzorowanie z wykorzystaniem miar

2.4.2 Wykonywanie akcji korygujących

Poziom 3 Dobrze określone

Do realizacji procesów stosowane są zaakceptowane dla całej firmy procedury.

Wykonywane praktyki:

3.1. Definiowanie standardowego procesu (na poziomie organizacji)

3.1.1 Standaryzacja procesu

3.1.2 Dostosowywanie standardowego procesu (do potrzeb określonych zastosowań)

3.2 Wykonywanie zdefiniowanego procesu

3.2.1 Wykorzystywanie dobrze zdefiniowanego procesu

3.2.2 Wykonywanie wspólnych przeglądów

3.2.3 Wykorzystywanie dobrze zdefiniowanych danych

Poziom 4 Sterowane ilościowo

Szczegółowe miary są zbierane i analizowane, co prowadzi do zrozumienia umiejętności oraz przewidywania rezultatów działania. Można ilościowo ocenić jakość produktów. Na podstawie uzyskanych wyników można podejmować decyzje wpływające na jakość produktów.

Wykonywane praktyki:

4.1. Określenie mierzalnych celów jakościowych

4.1.1 Określenie celów jakościowych

4.2 Obiektywne zarządzanie realizacją procesu

4.2.1 Określenie możliwości procesu

4.2.2 Wykorzystanie możliwości procesu

Poziom 5 Ciągła poprawa

Proces software’owy w firmie jest w sposób ciągły ulepszany na podstawie uzyskiwanych danych ilościowych.

Wykonywane praktyki:

5.1. Poprawianie możliwości organizacji

5.1.1 Ustanowienie celów dotyczących wydajności procesu

5.1.2 Ciągle poprawianie standardowego procesu

5.2 Poprawianie efektywności procesu

5.2.1 Wykonywanie analizy przypadków (błędów)

5.2.2 Usuwanie przyczyn błędów

5.2.3 Ciągłe poprawianie zdefiniowanego procesu.

Podstawowe czynności

Standard dzieli podstawowe czynności na pięć kategorii:

CUS – związane z relacjami pomiędzy dostarczycielem i klientem

ENG – czynności wytwórcze

PRO – czynności zarządcze związane z realizacją projektu

SUP – czynności wspomagające

ORG – czynności zarządcze realizowane na poziomie organizacji

Czynności związane z relacjami pomiędzy dostarczycielem i klientem to:

CUS.1 Nabycie produkt i/lub usługi software’owej

CUS.2 Ustanowienie kontraktu

CUS.3 Identyfikacja potrzeb klienta

CUS.4 Wspólne przeglądy i audity

CUS.5 Pakowanie, dostarczanie i instalowanie oprogramowania

CUS 6 Wsparcie działania oprogramowania

CUS.7 Obsługa klienta

CUS.8 Ocena zadowolenia klienta

Czynności wytwórcze to:

ENG.1 Określenie wymagań na system i projektowanie

ENG.2 Określenie wymagań na oprogramowanie

ENG.3 Opracowanie projektu oprogramowania

ENG.4 Implementacja projektu oprogramowania

ENG.5 Integracja i testowanie oprogramowania

ENG.6 Integracja i testowanie systemu

ENG.7 Pielęgnacja systemu i oprogramowania

Czynności związane z zarządzaniem projektem to:

PRO.1 Planowanie cyklu życia projektu

PRO.2 Ustanowienie planu projektu

PRO.3 Tworzenie zespołu projektowego

PRO.4 Zarządzanie wymaganiami

PRO.5 Zarządzanie jakością

PRO.6 Zarządzanie ryzykiem

PRO.7 Zarządzanie zasobami i harmonogramem

PRO.8 Zarządzanie poddostawcami

Czynności wspomagające to:

SUP.1 Opracowanie dokumentacji

SUP.2 Zarządzanie konfiguracją

SUP.3 Zarządzanie jakością

SUP.4 Rozwiązywanie problemów

SUP.5 Wspólne przeglądy

Procesy zarządcze na poziomie organizacji to:

ORG.1 Tworzenie biznesu

ORG.2 Definiowanie procesu

ORG.3 Ulepszanie procesu

ORG.4 Szkolenia

ORG.5 Umożliwienie ponownego wykorzystania (komponentów)

ORG.6 Dostarczenie środowiska produkcji oprogramowania

ORG.7 Zapewnienie środowiska pracy

Proces oceny

Ocena procesu jest wykonywana w celu poprawy możliwości firmy lub w celu oceny zdolności kontrahenta do wywiązania się ze zobowiązań. Ocena może być wykonywana jako samoocena, samoocena wspomagana z zewnątrz, samoocena weryfikowana z zewnątrz lub jako ocena niezależna. Ocena jest wykonywana poprzez porównanie procesów realizowanych ocenianej jednostce z modelowymi procesami opisanymi w podrozdziałach Klasyfikacja możliwości i Podstawowe czynności.

W trakcie wykonywania oceny należy stwierdzić, czy proces jest wykonywany. Jeśli jest wykonywany, to należy stwierdzić, czy jest wykonywany w sposób zalecany przez niniejszy standard. Jeśli procesy są wykonywane wielokrotnie, to należy zbadać co najmniej jedną instancję każdego procesu. Praktyki wspólne powinny być ocenione na skali dwuwartościwoej: istnieją / nie istnieją. Do oceny istniejących procesów wspólnych oraz oceny procesów podstawowych należy zastosować skalę: niewłaściwie realizowany (zawiera procesy nie realizowane w ogóle), częściowo zgodny z modelem, w wysokim stopniu zgodny z modelem, w pełni zgodny z modelem.

CMM

Capability Maturity Model został opracowany przez Software Engineering Institute w Carnegie-Mellon Uniwersity i opisuje czynności, które powinny być wykonywane w dobrze zorganizowanej firmie produkującej oprogramowanie. Zgodnie z założeniami autorów CMM może być wykorzystywany do:

Ulepszania procesu planowania, produkcji i pielęgnacji oprogramowania,
Oceny procesu produkcji oprogramowania we własnej firmie,
Oceny zdolności ewentualnych kontrahentów do wywiązywania się ze zobowiązań kontraktowych w zakresie zleceń software’owych.

CMM wyróżnia pięć głównych poziomów zaawansowania w produkcji oprogramowania:

1. Poziom początkowy,

2. Poziom powtarzalny

3. Poziom zdefiniowany,

4. Poziom zarządzany,

5. Poziom optymalizujący.

Poziom początkowy

Na poziomie początkowym w firmie nie są stosowane żadne konsekwentne procesy związane z planowaniem i realizacją przedsięwzięć software’owych. Działania takich firm są nieprzewidywalne. Sprawność procesu zależy od osobistych umiejętności poszczególnych członków zespołu wykonawczego. W sytuacjach kryzysowych istnieje tendencja do zwiększania nakładów pracy związanych z kodowaniem i testowaniem.

Pozostawanie firm na poziomie początkowym nie oznacza, że firmy takie nie wyprodukują żadnego oprogramowania. Ale ryzyko związane z realizacją projektów przez takie firmy jest bardzo duże. Prawie niemożliwe jest przewidzenie w jakim czasie i w jakim budżecie projekty zostaną zakończone.

Nie znam żadnych polskich wyników badań dotyczących zaawansowania według CMM firm w produkcji oprogramowania. Moje doświadczenia mówią mi jednak, że na pewno nie mniej niż 90% firm pozostaje właśnie na poziomie początkowym – i chyba nie są to szacunki zawyżone.

Poziom powtarzalny

Na poziomie powtarzalnym planowanie i zarządzanie projektami jest oparte na poprzednich doświadczeniach. Jeśli firma raz osiągnęła sukces w produkcji, można zakładać, że będzie potrafiła go powtórzyć w następnych projektach. Na tym poziomie firmy mają wdrożone mechanizmy zarządzania projektami. Opracowywane są realistyczne plany projektów. Ustanowione i przestrzegane są standardy dotyczące oprogramowania.

Procesami, które muszą być realizowane na poziomie powtarzalnym są:

Zarządzanie wymaganiami,
Planowanie projektów software’owych,
Kontrola i nadzór nad projektami,
Zarządzanie poddostawcami,
Zarządzanie jakością,
Zarządzanie konfiguracją.

Tych sześć procesów stanowią zasadniczą podstawę sterowalności projektów software’owych.

Należy zwrócić uwagę, że na poziomie powtarzalnym nie wymaga się jednorodności zarządzania wszystkimi projektami w całej firmie. Jeśli dla każdego projektu będą w jakikolwiek poprawny sposób realizowane powyższe procesy – firma będzie mogła być uznana za pracującą na poziomie powtarzalnym.

Przejście z poziomu początkowego na powtarzalny powoduje bardzo duży postęp w zaawansowaniu produkcji oprogramowania. Nad tym naprawdę warto pracować!

Poziom zdefiniowany

Na poziomie zdefiniowanym istnieje wspólny dla całej organizacji, udokumentowany i wdrożony proces produkcji, opisujący zarówno technologię jak i zarządzanie projektami. Dobrze zdefiniowany proces ma kryteria rozpoczynania faz, wejścia, standardy i procedury wykonywania prac, wyniki wraz ze sposobami ich weryfikacji i zatwierdzania. Koszt, harmonogram i funkcjonalność pozostają pod kontrolą. Celem istnienia tego procesu jest podniesienie wydajności w produkcji oprogramowania. Ogólny proces jest zawsze dostosowywany do potrzeb konkretnego projektu.

Procesami realizowanymi na poziomie zdefiniowanym są:

Ustalenie odpowiedzialności organizacyjnej za przebieg procesu software’owego
Zdefiniowanie procesu organizacyjnego
Program szkoleń
Zintegrowane zarządzanie oprogramowaniem

Inżynieria produktów software’owych

· Koordynacja międzygrupowa

· Wspólne przeglądy

Procesami z trzeciego poziomu CMM, które należy polecić do wdrożenia w pierwszej kolejności są wspólne przeglądy (ze względu na wysoką efektywność i niezbyt duże wymogi organizacyjne) oraz zdefiniowanie procesu organizacyjnego. Definiowanie procesu organizacyjnego można zacząć od przeglądu istniejących w firmie praktyk i wyboru spośród nich najbardziej dojrzałych jako standardów ogólnofirmowych. Oczywiście, zawsze będzie istniał problem nakłonienia grup, które nie są autorami przyjętych praktyk, do ich stosowania.

Poziom zarządzany

Poziom zarządzany koncentruje się na ilościowej ocenie procesu i jego wytworów – systemów. Zasadnicze procesy poziomu zarządzanego to:

Ilościowe zarządzanie produkcją
Zarządzanie jakością oprogramowania

Pewne standardy związane z mierzeniem produktów i procesu zwykle istnieją w każdej firmie: np. mierzenie czasu pracy czy liczenie liczby zgłoszonych przez użytkownika problemów. Ale pomiary takie są tylko wstępem do stworzenia pełnego systemu miar, dającego pogłębione spojrzenie na przyczyny występujących problemów (a czasami nawet sukcesów).

Poziom optymalizujący

Wdrożenie procesów powodujących ciągłe dostosowywanie i mierzalne ulepszanie procesu produkcji oprogramowania. Procesy na tym poziomie to:

Zapobieganie błędom
Zarządzanie zmianami technologii
Zarządzanie zmianami procesów

To już bardzo wysokie wymagania. W Polsce istnieje jedna firma pracująca na tym poziomie – jest to polski oddział wielkiej międzynarodowej korporacji.

Uwaga

Model CMM został w 2002 roku zastąpiony przez CMMI ^CM. Niektóre właściwości modelu CMMI ^SM są omawiane na podstronie Porównanie standardów PM.

Techniki specjalne

Czysty Pokój

Strategia Czystego Pokoju jest rodzajem przyrostowego podejścia do budowy oprogramowania. Ciąg przyrostów oprogramowania jest budowany przez małe niezależne zespoły. Po certyfikowaniu każdego przyrostu system jest integrowany jako (tymczasowa) całość.

Założenie: specyfikacja (modułu, funkcji) i jej dekompozycja definiują dokładnie te same funkcje, tzn. odwzorowują to samo wejście w takie samo wyjście. Jeśli spełnione jest to założenie projekt jest uważany za poprawny w stosunku do specyfikacji.

Ponieważ system jest produkowany przyrostowo, część funkcji z jednego przyrostu jest specyfikowana tylko zewnętrznie, jako zaślepki, które będą realizowane w następnych przyrostach.

Trzy rodzaje „skrzynek”:

Czarna skrzynka,
Skrzynka stanów,
Czysta skrzynka.

Czarna skrzynka

Czarna skrzynka definiuje zewnętrzne zachowanie systemu. Na podstawie aktualnego bodźca zewnętrznego i wiedzy o historii bodźców, które zadziałały na system, tworzona jest reakcja.

Skrzynka stanów

Skrzynka stanów przekształca aktualny bodziec i aktualny stan w odpowiedź systemu i nowy stan.

Czysta skrzynka

Czysta skrzynka jest to specyfikacja funkcji realizującej skrzynkę stanów. Zdefiniowanie takiej funkcji zwykle wprowadza nowe czarne skrzynki, dla których trzeba wykonać dalszy ciąg procesu.

Struktury skrzynkowe mogą być stosowane w podejściu każdym podejściu, w szczególności w podejściu funkcjonalnym albo obiektowym. Przy podejściu obiektowym czarna skrzynka specyfikuje zachowanie obiektu, skrzynka stanów definiuje enkapsulację danych, a czysta skrzynka definiuje usługi.

Przyrost #1

SSP

TSW

Przyrost #2

Przyrost #3

Struktura strategii Czystego Pokoju

IS Inżynieria Systemu. Ogólna specyfikacja systemu. Po wyspecyfikowaniu przyrostów odbywa się planowanie każdego z nich, opracowywany jest harmonogram integracji.

ZW Zbieranie Wymagań. Określanie wymagań biznesowych dla inkrementu.

SSS Specyfikacja Struktury Skrzynek Wyodrębnienie i określenie zachowania, danych i procedur na każdym poziomie szczegółowości. Tworzenie czarnych skrzynek.

FP Formalne Projektowanie. Wyodrębnianie funkcji i ich zachowań. Tworzenie skrzynek stanów i czystych skrzynek.

WP Weryfikacja Poprawności. Sprawdzanie poprawności specyfikacji skrzynek każdego rodzaju. Dla każdej struktury sterowania (sekwencja, while, if_then_else_, ....) stosowane są warunki poprawności. Zasadniczy krok wpływający na jakość tworzonych produktów.

GK Generowanie Kodu. Specyfikacja struktur skrzynkowych (opisana w specjalizowanym języku) jest programowana w określonym języku.

IK Inspekcja Kodu. Techniki „przejść” („walkthrough”) i inspekcji są stosowane w celu zapewnienia zgodności ze specyfikacją skrzynek i składniowej poprawności kodu. Wykonywana jest ostateczna weryfikacja poprawności kodu.

PT Planowanie Testów. We współpracy z przyszłymi użytkownikami analizowane jest przewidywane wykorzystanie oprogramowania i projektowane są testy uwzględniające rozkład prawdopodobieństwa wykorzystania. Planowanie Testów odbywa się równolegle ze specyfikacją, weryfikacją i generowaniem kodu.

TSW Testowanie Statystycznego Wykorzystania. Testowanie odbywa się z uwzględnieniem prawdopodobieństw wykorzystania przez całą docelową populację użytkowników.

C Certyfikacja. Po wykonaniu weryfikacji, inspekcji i testowania wykorzystania oraz usunięciu wszystkich błędów, inkrement jest certyfikowany. Dla każdego komponentu miara niezawodności (MTTF, Mean Time To Failure) musi być wyliczona. Proces certyfikacji zawiera następujące etapy:

Utworzenie scenariuszy użytkownika.
Określenie profilu wykorzystania.
Wygenerowanie przypadków testowych na podstawie profilu wykorzystania.
Wykonanie testów, zapisanie i analiza danych o błędach.
Wyliczenie niezawodności i certyfikacja.

Zasadnicze cechy procesu Czystego Pokoju gwarantujące wysoką jakość oprogramowania to połączenie formalnych metod projektowania, technik związanych z przeglądami oraz testowania statystycznego. Minimalizowana jest rola testowania jednostkowego – uważa się, że metody formalne i przeglądy eliminują większość błędów.

Technologia Czystego Pokoju gwarantuje uzyskanie bardzo niskiego poziomu błędów, niemożliwego przy stosowaniu innych technologii.

Źródło

Mills, H. D., M. Dyer, R. Linger, “Cleanroom Software Engineering”, IEEE Software, vol. 4, no. 5, September 1987, pp. 19-24.

Poka-yoke

Urządzenie poka-yoke – jest to mechanizm zapobiegający powstawaniu błędów lub szybko wykrywający jego zaistnienie. Można także mówić o technikach poka-yoke – sposobach wykonywania procesów w sposób uniemożliwiający (utrudniający) powstanie błędów. Pojęcie zostało zdefiniowane przez japońskiego inżyniera Toyoty Shigeo Shingo.

Podejście poka-yoke tworzy specjalne podejście do projektowania oprogramowania. W każdym momencie należy zadać sobie pytanie: jakie problemy może spowodować przyjęty sposób realizacji oprogramowania? Następnie dla zidentyfikowanych problemów należy zaprojektować takie własności aplikacji, które będą minimalizowały lub usuwały prawdopodobieństwo wystąpienia takiego problemu. Urządzenia poka-yoke mają następujące właściwości:

Są proste i tanie,
Są częścią procesu na rzecz którego pracują,
Są zlokalizowane w pobliżu miejsca, gdzie błąd może powstać.

Do technik poka-yoke mogą być zaliczone weryfikacje kompletności realizacji zadań. Za proste urządzenia poka-yoke można uznać fragmenty kodu, wewnętrznie weryfikujące pracę innych elementów oprogramowania.

Przykład 1

Urządzenie poka-yoke szybko wykrywające błąd. Tworzona jest dwuwymiarowa tablica rozkładu wartości sprzedaży. Wartość jest klasyfikowana według województwa i miesiąca sprzedaży. Każdy wiersz odpowiada jednemu województwu, każda kolumna – jednemu miesiącowi. Komórka raportu przedstawia sprzedaż w określonym województwie w danym miesiącu. Ostatnia kolumna to suma sprzedaży w województwie (w roku), ostatni wiersz – suma sprzedaży w miesiącu (w całym kraju). Urządzenie poka-yoke sprawdza, czy suma wartości w ostatniej kolumnie (łączna sprzedaż) jest równa sumie wartości w ostatnim roku i ewentualnie komunikuje błąd.

Przykład 2

Jednym z podstawowych zadań systemu finansowo-księgowego jest ewidencjonowanie dokumentów źródłowych. Dokumenty są najpierw wpisywane w postaci źródłowej, a następnie zatwierdzane. Kolejność zatwierdzania dokumentów zależy od operatora systemu. Podpowiadanie zestawu niezatwierdzonych dokumentów źródłowych można uznać za prostą technikę zapobiegającą pomyłce. Sprawdzenie w momencie zakończenia pracy czy wszystkie dokumenty zostały obrobione jest techniką poka-yoke wspomagającą wczesne wykrywanie błędu..

Co zrobić z ustawą Prawo Zamówień Publicznych?

Co zrobić z Urzędem Zamówień Publicznych?

Kto ma wygrywać publiczne przetargi?

Czy najniższa cena oferty gwarantuje najniższy koszt?

Program rozwoju sportu

Wiedza o projektach

Model zarządzania wiedzą o projektach

Wiedza o projektach

Zarządzanie projektami nastawione na wiedzę

Agregaty projektów

Rodziny projektów

Agregaty projektów