Czy jest zarządzanie jakością? Analiza zarządzania jakością

Zarządzanie jakością w IT
Czy jest zarządzanie jakością?
Zarządzanie jakością, między innymi, to:
•identyfikacja standardów, które odpowiadają wymaganiom projektu
•wykonywanie zaplanowanych procesów tak aby zostały spełnione wymagania projektu,
•śledzenie wyników projektu,
•analiza czy zaplanowane standardy jakości są spełnione,
•identyfikacja sposobów wyeliminowania elementów nie spełniających norm jakości.
Z innego punktu widzenia zarządzanie jakością to:
•planowanie jakości,
•zapewnianie jakości,
•kontrola jakości.
Kontrola jakości ma za zadanie weryfikować, czy produkt spełnia wymagania jakości, w przeciwieństwie do
zapewniania jakości. Zapewnienie jakości (Quality Assurance) definiuje i optymalizuje procesy, które są
używane podczas wytwarzania produktu.
Tyle w teorii..., ale czy można te formalizmy nałożyć na codzienną pracę, na przykład dostarczając usługę
instalacji i konfiguracji platformy z systemem zarządzania danymi lub wytwarzając nową aplikację? Tak.
Wymaga to trochę czasu i wysiłku, ale w efekcie dostarczane rozwiązania będą wysokiej jakości produktami.
Metody, standardy, rozwiązania, aplikacje, oraz skróty użyte w tym artykule są szerzej opisane w dostępnych
publikacjach w Internecie, do których, pod koniec tego artykułu, zostały udostępnione linki.
Analiza zarządzania jakością
Prawidłowe zarządzanie jakością musi uwzględniać wiele elementów. Nie ma stałej listy zadań, która musi
zrealizowana przez osoby odpowiedzialne za zarządzanie i kontrolę jakości. Należy analizować, obserwować i
wyciągać wnioski z bardzo szerokiej palety sytuacji, które mają wpływ na jakość, na przykład:
•Odpowiedzialność całego zespołu za jakość - Nie można definiować zarządzania jakością jako zadania, za które
odpowiedzialny jest kierownik projektu lub inny przełożony (choć niektóre metodologie mówią inaczej).
Jakość wynika z pracy całego zespołu: programistów, testerów, architektów, analityków i administratorów.
Kierownik projektu natomiast powinien dostać po głowie od klienta, za to, że jakość jest nieodpowiednia.
Przykład:
Jakość wytwarzanego kodu jest zależna od tego, czy zespół dysponuje wspólnymi zasadami programowania.
Warto poszukać dokumentów, w których zawarte są dobre praktyki i zaadaptować je do swojego zespołu, jak
na przykład Dotnet Spider Best Practises. Można też wykorzystywać darmowe narzędzia do kontroli
standardów kodowania, takie jak FXCop. Dzięki standardom zwiększamy stabilność, możliwość rozwoju
(elastyczność) i upraszczamy zarządzanie kodem.
•Zadowolenie klienta - zarządzanie jakością jest dynamiczne, i musi się dostosować do wymagań klienta.
Wszystkie działania muszą dążyć do tego, aby jakość była wysoce zadowalająca, ale musi być także zgodna ze
standardami wewnętrznymi w firmie, projekcie i zespole.
•Ciągły rozwój - Total Quality Management is not a destination but a journey toward improvement, czyli Pełne
zarządzanie jakością to nie cel a podróż ku doskonałości -jakość musi ewoluować, i musi być ciągle ulepszana.
Wydrukowano w dniu 2017-03-04 13:37
Nie ma produktów idealnych.
Błędne zarządzanie jakością można zidentyfikować poprzez obserwację oraz analizę projektu i produktu.
Wykrywając niską jakość rozwiązania, powtarzające się błędy oraz niedozwolenie klienta, jesteśmy w stanie
określić błędy zarządzania jakością.
Przykład:
Od kilku godzin prowadzona jest instalacja pełnego środowiska SharePoint 2010. W ostatnim etapie, podczas
uruchomienia SharePoint 2010 Products Configuration Wizard pojawia się błąd:
Unrecognized attribute 'allowInsecureTransport'.
Rozwiązaniem problemu na szybko jest zainstalowanie poprawki KB9776462 dla Windows Server 2008 R2. Nie
można jednak oczekiwać, że każdy administrator będzie od razu to wiedział. Stres wywołany błędem pod
koniec ostatniego etapu instalacji i konfiguracji, wydłuży czas pracy i być może spowoduje dalsze błędy.
Rozwiązaniem problemu w kontekście zarządzania jakością jest precyzyjne zdefiniowanie zadań podczas
procesu wstępnej analizy środowiska klienckiego. W tym przypadku wyraźnie widać, że środowisko nie ma
aktualnych poprawek, więc osoba przeprowadzająca instalację środowiska powinna być na to przygotowana,
instalując wymagane poprawki lub zlecić to w dziale IT firmy, w której wykonujemy wdrożenie. Proces wstępnej
analizy środowiska powinien zawierać zadanie, które polega na sprawdzeniu stanu aktualizacji poprawek
środowiska.
Powyższe przykłady nie są rozwiązaniem problemu jakości, ale jedynie początkiem drogi dla każdego, który
chce na poważnie uwzględniać ją w swojej codziennej pracy. Wszystkie zawarte tu obszary i opisy nie
odzwierciedlają w pełni tego, co należy traktować jako jakość - tu zawarte są przykłady, dzięki którym można
zrozumieć jakość jako niezbędny element w każdym zadaniu.
Metody i standardy
Najbardziej rozpowszechnionym standardem, od którego wywodzi się wiele metod jest ISO/IEC 9126 Software engineering - Product quality. Standard ten definiuje model oraz różnego typu metryki, które
określają jakość produktu. Model uwzględnia takie obszary jak:
•Funkcjonalność
•Niezawodność
•Użyteczność
•Wydajność
•Łatwość utrzymania
•Przenośność
W zarządzaniu jakością warto wspomagać się jakąś metodą, a rynek oferuje ich wiele, także wspieranych przez
zaawansowane strategie zarządzania. Kontrola statystyczna procesów (Statistical Process Control) na przykład
pozwala na kontrolowanie procesów do tego stopnia, że zaczynają się zachowywać przewidywalnie.
Narzędziami SPC są wykresy oraz kluczowe czynniki wydajności (KPI), które wyznaczają w wartościach
liczbowych możliwości procesu i określają ryzyko utraty jakości produktu.
Ciekawym podejściem do zaplanowania jakości jest metoda Design Of Experiments (DOE). Uproszczając, jest to
rozwiązanie polegające na zbieraniu informacji podczas eksperymentowania z rozwiązaniem, wyszukując
elementów, które mogą być niestabilne z punktu widzenia jakości.
Wydrukowano w dniu 2017-03-04 13:37
Przykład
Przechodząc od wymagań klienta do implementacji należy uwzględnić wiele aspektów, których klient nie
uwzględnił w specyfikacji, ale na pewno nam wytknie jako nasz błąd. Kiedy klient wymaga aby rozwiązanie było
bezpieczne, my musimy brać pod uwagę wiele elementów, których klient nie wyspecyfikował. Najprostszym
przykładem jest konfiguracja kont użytkowników:
•Konta nie używane powinny być usunięte z serwera (włączając to w konto Guest)
•Nazwa konta Administrator powinna zostać zmieniona
•Stworzyć osobne konta do obsługi usług (Services)
•Zdefiniować poprawnie grupy dostępu do odpowiednich kolekcji witryn w SharePoint
Tworząc środowisko, możemy eksperymentować, i wyszukiwać tych elementów, które nie spełnią wymagań
klienta i co mogą wpłynąć na negatywną opinię o jakości produktu i projektu. W ten sposób także generujemy
jakość.
Wyniki planowania jakości
Planowanie jest w pełni zależne od standardów zdefiniowanych dla projektu. Planowanie nie jest procesem
jednorazowym, a ciągłym. W żaden sposób nie powinno się zamykać możliwości zwiększenia jakości, tylko
dlatego, że proces planowania został zakończony. Z drugiej strony jednak należy pamiętać, że dobrze
zaplanowana jakość na początku projektu skutkuje w obniżeniu jego kosztów, wyższej produktywności
pracowników i wyższemu zadowoleniu klienta. Planowanie jakości to dobór odpowiedniej metodyki oraz
oszacowanie kosztów jakości.
Ważnym aspektem jest zdefiniowanie kosztów jakości. Należy przeliczyć zyski i straty każdego kroku, który
podejmiemy, celem zapewnienia jakości.
Przykład
Narzucenie standardów kodowania spowoduje najprawdopodobniej zmniejszenie ilości błędów w
wygenerowanym kodzie. Dostarczając przewidywalny kod, jesteśmy także w stanie o wiele sprawniej wykryć
usterki. Usuwanie błędów w rozwijanym produkcie jest z czasem coraz bardziej kosztowne. Ustanowienie reguł
kodowania w dużej mierze zmniejsza ilość czasu, potrzebną na wykrycie i usunięcie problemu. Zatem
jednorazowy koszt stworzenia i wdrożenia standardów kodowania może być mniejszy od kosztów usuwania
błędów, których można było uniknąć poprzez spójne metody wytwarzania kodu.
Przykład
W przypadku SharePoint 2010, nie zalecane jest tworzenie widoków, prezentujących do 5000 elementów.
Przekroczenie tej wartości (choć jest to wartość konfigurowalna) może spowodować bardzo duże problemy z
wydajnością.
W tym przykładzie należy oszacować koszt naprawy rozwiązania, kiedy okaże się, że nie jest wydajne.
Być może w przypadku, gdy ograniczenie SharePoint stoi w konflikcie z wymaganiami klienta, trzeba będzie
poszukać alternatywnych rozwiązań co może zwiększyć koszty ale na pewno nie będzie trzeba naprawiać
rozwiązania (zmniejszone koszty) ponieważ planowanie jakości wyeliminowało ten błąd na początku procesu
produkcji.
Co może być wynikiem planowania jakości? Wynikiem powinien być plan. Istotą zarządzania jakością jest
analiza i wyciąganie wniosków, zatem plan nie musi być doskonały, ale na pewno musi być przemyślany. Wynik
zatem musi zawierać rozwiązania na problemy, które przewidzieliśmy i których się spodziewamy. Aczkolwiek
Wydrukowano w dniu 2017-03-04 13:37
nie można pomijać sytuacji, których przewidzieć nie jesteśmy w stanie, ale możemy się przygotować i
zareagować, minimalizując ewentualne straty.
Plan nie może być zamknięty, ponieważ analiza w trakcie projektu może wykazać, że potrzebne są następne
korekty produktu, które potencjalnie zwiększą jego jakość. Zatem konstrukcja musi być otwarta na nowe
zadania i procesy. Jest to niezwykle istotne dla długotrwających projektów.
Dla osób, które chciałyby zacząć planować wysokiej jakości wdrożenia SharePoint, polecam zapoznać się z
przykładowymi szablonami projektu wdrożenia udostępnionymi przez firmę Microsoft. Link jest dostępny
poniżej.
Wydrukowano w dniu 2017-03-04 13:37