BETA
Aby się zalogować, najpiew wybierz portal.
Aby się zarejestrować, najpiew wybierz portal.
Podaj słowa kluczowe
Słowa kluczowe muszą mieć co najmniej 3 sąsiadujące znaki alfanumeryczne
Pole zawiera niedozwolone znaki

Baza wiedzy











Zarządzanie jakością w IT

22-02-2011 08:00 | Michał Bojko
Michał Bojko wprowadza czytelnika w tematykę zarządzania jakością w IT. Z artykułu dowiemy się: czym jest zarządzanie jakością, jak prawidłowo zarządzać jakością oraz poznamy metody i standardy w zarządzaniu jakością.

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. 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.

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 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.

Linki - więcej informacji

 

Autor: Michał Bojko

Zawodowo kierownik projektów rozwiązań bazujących na platformie SharePoint. Prywatnie między innymi organizator konferencji o SharePoint (SharePoint 2010 Community Launch, Time For SharePoint 2010, Time For SharePoint 2011).
Obecnie posiada certyfikaty Professional SCRUM Master I, MCP i MCTS (SQL Server 2005, Project 2007, MOSS 2007).

Podobne artykuły

Komentarze 2

Łukasz Rutkowski Microsoft
Łukasz Rutkowski
745 pkt.
Senior
22-02-2011
oceń pozytywnie 0

Drobny błąd = KB9776462 <> KB976462 :)

Michał Bojko Ekspert WSS
Michał Bojko
1072 pkt.
Senior
MVP
22-02-2011
oceń pozytywnie 0

racja - literówka :)

pozdrawiam Michał Bojko

 

pkt.

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.