Planowanie jakości

Obecny rynek, nie tylko usług IT, przykłada dużą wagę do jakości. O jakości mówi się głośno, akcentując jej znaczenie w osiągnięciu satysfakcji klienta oraz sukcesu produktu. Oceniając produkty, stwierdzamy „to jest (nie jest) dobrej jakości”, „oczekuję wyższej jakości” itp. Intuicyjnie rozumiemy znaczenie pojęcia „jakość”, choć nierzadko mamy problemy z podaniem definicji tego terminu. Zanim przejdziemy do planowania jakości w projekcie, warto zdefiniować samo pojęcie jakości.

Istnieje wiele definicji jakości, wśród których najbardziej popularne są następujące:

• „Jakość to stopień, w jakim zbiór inherentnych właściwości spełnia wymagania.” wg ISO 9000:2001.
• „Jakość jest to pewien stopień doskonałości.” Platon.
• „Jakość to zgodność z wymaganiami.” Crosby.

Definicje Platona oraz Crosby’ego wydają się prostsze, w definicji ISO wątpliwości może budzić użycie słowa „inherentny”. „Słownik wyrazów obcych i zwrotów obcojęzycznych“ Kopalińskiego  definiuje to słowo jako „tkwiący w czymś w istocie, strukturze, zasadniczym charakterze czegoś, w naturze, w ustalonych obyczajach; nieodłączny od”. Inherencja oznacza cechę nierozerwalnie związaną z danym pojęciem; cechę, która przesądza o istocie i naturze produktu, bez której produkt nie byłby tym, czym jest.

Przykładowo inherentną właściwością systemów opartych na przepływach (ang. workflow) jest przetwarzanie obiegu dokumentu, zadania czy innego typu obiektu za pomocą zdefiniowanego przepływu statusów ze ściśle określonymi warunkami przejść między konkretnymi statusami.

Kolejny ważny element definicji nawiązuje do kwestii „spełniania wymagań”. Tu pojawia się problem, gdyż często nie znamy wszystkich wymagań użytkowników, klienta i innych interesariuszy, bądź są one sprzeczne. W takim przypadku jednoznaczne określenie, czy dany produkt jest wysokiej, czy niskiej jakości, staje się szczególnie trudne. Odnosząc tę kwestię do obszaru inżynierii wymagań, można stwierdzić, że zaplanowanie produktu, który docelowo zostanie uznany jako produkt wysokiej jakości przez określoną grupę odbiorców, jest bardzo trudne. Dlaczego? Składa się na to kilka aspektów:

• nie wszystkie wymagania są podane przez klienta,
• nie znamy wszystkich interesariuszy, przez co nie wiemy, kogo pytać o wymagania,
• nie wszystkie wymagania są wykonalne,
• wymagania bywają sprzeczne.

Rozwiązanie (przynajmniej w pewnym stopniu) wymienionych kwestii należy do zadań inżyniera wymagań. Jego odpowiedzialnością jest ujawnienie wymagań, których interesariusze mogą sobie nie uświadamiać, a które okazują się krytyczne dla poprawności i kompletności produktu.

Problemy z ustaleniem wymagań mogą sprawić, że gotowy produkt nie spełni definicji „wysokiej jakości” w sposób rozumiany przez interesariuszy. Z tego powodu jednym z istotnych elementów składających się na jakość gotowego produktu jest skuteczny proces inżynierii wymagań. Czynności inżynierii wymagań pozwalają odpowiedzieć na pytania:

• Kto jest interesariuszem projektu? Kto będzie miał wpływ na jego przebieg? Kto będzie zgłaszać ograniczenia wpływające na sposób realizacji czy zakres projektu?
• Kto jest głównym odbiorcą produktu? W jakim środowisku pracuje? Jakie problemy ma rozwiązać wytwarzany produkt?
• Kto jest pośrednim odbiorcą/użytkownikiem produktu? W jaki sposób działanie tej osoby może wpłynąć na postać czy zestaw cech produktu?
• Jakie są oczekiwania, potrzeby i wymagania interesariuszy projektu? Jakie są wymagania funkcjonalne i niefunkcjonalne produktu?
• Czy istnieją sprzeczne wymagania? Kto jest ich twórcą? W jaki sposób można usunąć sprzeczności?
• Jakie ograniczenia wewnętrzne i zewnętrzne mogą wpłynąć na projekt i produkt?

Odpowiedzi na wymienione pytania (w gruncie rzeczy zadawane bezpośrednio podczas identyfikacji i analizy wymagań) pozwalają określić, co jest celem projektu, jakich cech oczekujemy od produktu oraz jak ma być realizowany projekt. Informacje te ułatwią ustalenie wymaganego poziomu jakości produktu, a tym samym opracowanie planu zapewnienia jakości w projekcie.

W stworzeniu planu jakości mogą pomóc uniwersalne zasady skutecznego działania Stephena Covey‘a [Covey].

Zasady Covey’a.

• Bądź proaktywny.
• Zaczynaj, mając koniec na względzie.
• Aby rzeczy pierwsze były pierwsze.
• Myśl o obopólnej korzyści.
• Najpierw staraj się zrozumieć.
• Dbaj o synergię.
• Ostrz piłę.

O znaczeniu zasad Covey’a świadczy chociażby opinia Eda Yourdona, światowej sławy eksperta w zakresie inżynierii oprogramowania, który stwierdził, że dla osób związanych z wytwarzaniem oprogramowania zasady Covey’a są ważniejsze niż szczegółowe techniki prezentowane w opasłych tomach dotyczących inżynierii oprogramowania.

Druga zasada Covey’a nakazuje zaczynać [prace], mając koniec [wynik] na względzie. Odnosząc ją do projektu (także informatycznego), końcem jest dostarczenie produktu (oprogramowania) i jego akceptacja przez klienta. Aby zwiększyć szanse osiągnięcia wyniku, należy kontrolować jakość i dbać o nią od początku przedsięwzięcia, stosując następujące kroki:

• Planowanie czynności zapewnienia i kontroli jakości przy uwzględnieniu wymagań interesariuszy. Czynności te mogą obejmować użycie odpowiednich standardów i dobrych praktyk, zastosowanie kryteriów jakościowych dla różnego typu produktów pośrednich i gotowego produktu, zastosowanie przeglądów specyfikacji wymagań i projektu, testy weryfikujące jakość wytwarzanego produktu bądź jego części.
• Realizacja zaplanowanej uprzednio czynności zapewnienia jakości i kontroli jakości.

Podczas planowania jakości można wspomagać się doświadczeniem wynikającym z klasycznych zagadnień zarządzania jakością. Oprócz zasad Covey’a warto wspomnieć o ośmiu wymiarach jakości, koncepcji opracowanej przez Davida Garvina z  Harvard Business School.

Wymiary jakości Garvina:

• Wydajność,
• Niezawodność,
• Wytrzymałość,
• Łatwość naprawy,
• Estetyka,
• Cechy funkcjonalne,
• Reputacja,
• Zgodność ze standardami i wymaganiami.

Warto zauważyć, że klasyfikacja Garvina pokrywa się z tzw. modelem jakości oprogramowania zaproponowanym przez  normę ISO/IEC 25010:2011 (poprzednio ISO/IEC 9126).

Pierwszy z wymiarów jakości Garvina dotyczy szeroko rozumianej wydajności. W kontekście branży IT i jej produktów przykładem wydajności rozwiązań informatycznych może być szybkość przetwarzania operacji przez system liczona w transakcjach na minutę.

Drugim wymiarem jakości jest niezawodność. Jest ona zwykle rozumiana jako częstotliwość pojawiania się błędów podczas działania danego rozwiązania (systemu) lub jako tak zwany MTBF (ang. Mean Time Before Failures) – czyli średni czas między awariami.

Kolejnym wymiarem jakości jest wytrzymałość. O ile łatwo ją zdefiniować w odniesieniu do sprzętu i przedmiotów materialnych, o tyle z oprogramowaniem jest pewien problem, ponieważ oprogramowania nie da się uszkodzić fizycznie. Dlatego w przypadku produktów informatycznych wytrzymałość rozumiana jest jako czas pracy danego rozwiązania bez konieczności wprowadzania istotnych modyfikacji.

Czwartym wymiarem jakości jest łatwość naprawy. Cecha ta w dużej mierze odpowiada jakości projektu – jeśli rozwiązanie zaprojektowano modularnie, wykorzystując sprawdzone wzorce, dbając o jakość i przejrzystość kodu, to z dużym prawdopodobieństwem można przyjąć, że jego naprawa będzie łatwiejsza niż w przypadku oprogramowania o strukturze monolitycznej.

Na piątym miejscu listy wymiarów jakości plasuje się estetyka. W przypadku oprogramowania estetyka wiąże się głównie z interfejsem użytkownika i wrażeniach estetycznych dostarczanych odbiorcom.

Kolejny wymiar jakości to funkcjonalność – czyli wymagania funkcjonalne, determinujące, czy dany produkt dostarczy odbiorcom wszystkich pożądanych przez nich funkcji i usług potrzebnych im do efektywnej pracy.

Następny element składający się na jakość planowanego produktu to reputacja wytwórcy. Znaczenie tego parametru jest szczególnie widoczne w przypadku takich produktów jak samochody, sprzęt RTV i AGD czy zegarki, których marka często przesądza o wyborze. W przemyśle informatycznym znaczenie tego parametru jest nieco mniejsze, jednak nadal wyraźnie zauważalne (na przykład w przypadku wyboru między oprogramowaniem znanych firm a oprogramowaniem pochodzącym od mało rozpoznawalnych dostawców, nierzadko darmowym).

Ósmym wymiarem jakości według Garvina jest zgodność ze standardami i innymi wymaganiami. Przykładem jest wymóg zgodności tzw. systemów bezpieczeństwa krytycznego z odpowiednimi normami branżowymi.

Kryteria jakości, zarówno Garvina, jak i te pochodzące od innych autorów i źródeł, składają się na proces planowania jakości produktu. Wiedząc, „jaki” powinien być produkt, musimy zaplanować czynności, które pozwolą osiągnąć ten pożądany stan końcowy. 

Mówiąc o zarządzaniu jakością, należy wyjaśnić pojęcia składające się na ten proces.

Zapewnienie jakości (ang. Quality Assurance) to „część zarządzania jakością ukierunkowana na zwiększenie zdolności spełniania wymagań dotyczących jakości” [ISO 9000:2001].

Inna definicja uznaje zapewnienie jakości za „zaplanowane i systematyczne działania realizowane w ramach systemu jakości, aby zostały spełnione wymagania jakościowe dla danego produktu lub usługi” [American Society for Quality™(ASQ)]

Kontrola jakości – techniki obserwacyjne i działania stosowane w celu spełnienia wymagań w zakresie jakości [American Society for Quality™(ASQ)].

Innymi słowy, zapewnienie jakości to proces służący spełnieniu minimalnego wymaganego poziomu jakości produktu czy usługi, podczas gdy kontrola jakości polega na monitorowaniu stanu obecnego w celu weryfikacji spełnienia poziomu jakości oraz wdrożenia odpowiednich działań korekcyjnych w razie potrzeby.

W kontekście oprogramowania zapewnienie jakości jest określane akronimem SQA (ang. Software Quality Assurance) i ma na celu ustalenie metod, technik, procesów umożliwiających „wbudowanie” określonego poziomu jakości do produktu informatycznego. Planowane czynności SQA mogą obejmować:

• stosowanie metod technicznych (np. testy jednostkowe kodu),
• testowanie oprogramowania,
• wymuszenie użycia standardów i kryteriów jakości,
• kontrolowanie zmian,
• wykonywanie pomiarów jakości procesu i produktów,
• systematyczne wykonywanie przeglądów dokumentacji analitycznej i projektowej,
• przeprowadzanie formalnych przeglądów technicznych (FTR – Formal Technical Review),
• zapisywanie i raportowanie.

Ważnym pojęciem związanym z zarządzaniem jakością jest TQM (ang. Total Quality Management). Zarządzanie przez jakość (znane również pod pojęciami kompleksowe zarządzanie przez jakość, kompleksowe zarządzanie jakością, totalne zarządzanie jakością) to sposób zarządzania organizacją, w którym każdy aspekt działalności uwzględnienia promowanie jakości. W procesie tym uczestniczą wszyscy członkowie organizacji, dlatego ważnym elementem koncepcji TQM jest praca zespołowa, zaangażowanie, samokontrola i stałe podnoszenie kwalifikacji. Celem wszystkich czynności jest osiągnięcie długotrwałego sukcesu w działalności biznesowej, którego źródłem w znaczącym stopniu jest zadowolenie klienta. Aby osiągnąć ten cel, TQM wprowadza zestaw działań sprawiających, że każdy członek organizacji, niezależnie od zajmowanego stanowiska, ma świadomość oczekiwań i potrzeb klientów swojej organizacji i dąży do ich spełnienia. Najważniejszym elementem TQM jest klient.

Brzmi to całkiem prosto, jednak w praktyce prawidłowe zrozumienie i spełnianie oczekiwań klientów bywa dla organizacji ogromnym wyzwaniem (również psychologicznym) i wymaga odpowiednich procesów.

Podejście Total Quality Management powstało pod koniec lat siedemdziesiątych w Japonii i zostało rozwinięte w USA w połowie lat osiemdziesiątych.

U podstaw koncepcji TQM leżą zasady Deminga, obejmujące między innymi [Deming]:

• stałą dbałość o doskonałość produktu, służącą spełnieniu potrzeb klientów w możliwie największym stopniu,
• budowanie przekonania o konieczności wdrożenia zintegrowanego systemu zarządzania jakością,
• zaufanie do jednego dostawcy,
• stałe usprawnianie procesów wpływających na jakość,
• wdrożenie nowoczesnych metod nadzoru.

TQM to nie tylko zasady Deminga, ale również reguły ciągłego doskonalenia procesów (kaizen) oraz „zero błędów”.

Słowo kaizen pochodzi od japońskich słów kai (zmiana) oraz zen (dobry) odzwierciedlających istotę tej filozofii – wprowadzanie dobrych zmian służących doskonaleniu produktu oraz zwiększenie postrzegania jakości przez samego producenta. W praktyce kaizen to zbiór skutecznych narzędzi wprowadzania i utrzymywania zmian w procesach i zasobach organizacji.

Zasada „zero błędów” z kolei oznacza produkcję bezusterkową, czyli takie planowanie, organizację i wykonanie procesu produkcyjnego, które całkowicie wyeliminuje błędy zarówno procesu, jak i samego produktu.

Koncepcja TQM łączy elementy wielu podejść, zasad i filozofii, czerpiąc z nich do zbudowania własnych zasad. Zasady TQM to:

• Jakość może i musi być zarządzana.
• Każdy ma swojego klienta i swojego dostawcę.
• Procesy, a nie ludzie, stanowią problem.
• Każdy pracownik jest odpowiedzialny za jakość.
• Problemom trzeba zapobiegać, a nie tylko rozwiązywać.
• Jakość musi być mierzona.
• Poprawa jakości musi być stała.
• Standard jakości jest wolny od defektów.
• Cele wynikają z wymagań, a nie negocjacji.
• Koszty są w ukryte w całym cyklu życia, a nie tylko w wytwarzaniu.
• Kierownictwo musi być zaangażowane i musi przewodzić.
• Działania na rzecz poprawy jakości muszą być planowane i organizowane.

W praktyce TQM polega na kierowaniu procesem produkcyjnym na wszystkich jego fazach zmierzającym i służącym do uzyskania produktu najwyższej jakości. Biznesową przesłanką TQM jest poprawa konkurencyjności i dochodowości firmy.

TQM jest możliwe do zastosowania w każdej dziedzinie przemysłu i biznesu. Da się je wdrożyć zarówno w fabryce aut, jak i w przedsiębiorstwie usługowym. W inżynierii oprogramowania zastosowanie zasad TQM może być następujące:

• Poprawa skuteczności i użyteczności fazy identyfikacji wymagań przez pełną identyfikację interesariuszy oraz pozyskanie wiedzy dotyczącej ich realnych potrzeb i oczekiwań. W tym celu potrzebna będzie nie tylko znajomość możliwych interesariuszy rozwiązania, ale i zaangażowanie ich w procesy identyfikacji wymagań w celu jak najdokładniejszego określenia oczekiwań względem produktu.
• Zaangażowanie użytkowników i klientów w przeglądy wyników analizy i specyfikacji wymagań, aby upewnić się, że inżynierowie wymagań prawidłowo zrozumieli i udokumentowali potrzeby interesariuszy.
• Zaangażowanie interesariuszy w fazie testowania.
• Zapewnienie szkoleń i wsparcia użytkownikom końcowym w momencie oddania rozwiązania do pracy produkcyjnej. Podczas szkoleń należy skupić się na wyjaśnieniu interesariuszom korzyści oraz możliwych zastosowań funkcji rozwiązania ze wskazaniem sposobów osiągnięcia celów i potrzeb biznesowych interesariuszy za pomocą danego produktu. Szkolenia powinny umożliwić użytkownikom obsługę produktu maksymalizującą efektywność pracy z systemem przy jednoczesnej eliminacji błędów.

Podczas fazy utrzymania ciągłe doskonalenie może przejawiać się monitorowaniem wydajności, użyteczności i przydatności produktu do potrzeb interesariuszy oraz wprowadzaniem niezbędnych ulepszeń i zmian zmierzających do poprawy jakości pracy z aplikacją lub/i rozszerzenia korzyści płynących z użytkowania systemu. Szczególnie istotnym elementem TQM w tej fazie jest obsługa wszelkich zgłoszeń, skarg, uwag płynących od użytkowników, ponieważ mogą one sygnalizować potrzebę wprowadzenia udoskonaleń w produkcie.  

Autorzy: Bartosz Chrabski, Karolina Zmitrowicz