Zapewnianie jakości
-
- Tomasz Byzia,
- 04.05.1998
Testowanie oprogramowania
Jest to forma przeglądu technicznego wykonywalnej specyfikacji programu. Jest procesem wykonywania programu z intencją znalezienia błędu. Takie podejście wymaga oczywiście przygotowania i zaplanowania testów oraz odpowiedniego czasu do ich przeprowadzenia na różnych poziomach aplikacji i w różny sposób. Typowym błędem kierowników projektu jest planowanie testowania tylko w kategoriach kolejnego elementu w harmonogramie projektu, a nie procedury jego realizacji.
Dowodzenie poprawności
Jest to kierunek przyszłościowy, choć w USA wymaga się, aby fragmenty kodu, które wdrażają algorytmy odpowiedzialne za bezpieczeństwo lub utrzymanie życia ludzkiego, były objęte formalnymi metodami dowodzenia ich poprawności.
Symulacje i prototypowanie
Prototyp w praktyce inżynierskiej jest wygodnym (a czasem jedynym) narzędziem służącym do zebrania doświadczeń z "realnego świata". Bardzo dobrze służy też do konfrontacji idei i oczekiwań użytkownika z rzeczywistością.
Śledzenie wymagań
Jest to zestaw technik koncentrujących się na szczegółowym i udokumentowanym śledzeniu wymagań użytkownika od momentu ich powstania, przez analizę, projekt, i wdrożenie i testowanie, z nadzieją, że ta "troskliwa obecność" przyczyni się do najlepszego ich zrealizowania.
Inne narzędzia
Kwalitologia dysponuje bogatym zestawem specyficznych narzędzi, którymi można się posługiwać przy analizie i planowaniu jakości. Są to np. histogramy, diagramy Pareto, diagramy "rybich ości", analiza FMEA, statystyczna kontrola procesów itd. Nawet pobieżny ich opis daleko wykracza poza temat artykułu.
1. Wysoka jakość pojawia się tam, gdzie się jej oczekuje (Crosby).
2. 80% problemów jakościowych powoduje kierownictwo, nie pracownicy (Juran).
3. "Kierownictwo bierze pieniądze za myślenie, pracownicy za wykonywanie poleceń". Są to ostatnie słowa, które słyszy jakość, opuszczając projekt.
4. Jakość jest tym, czego brak oznacza stratę dla wszystkich (Taguchi).
5. Wydajność testowania to 2-4 błędów/godz., a przeglądów 10-12 błędów/godz. Pracochłonność poprawy błędów wykrytych w testowaniu to 10-40 godz./błąd, a w wyniku przeglądu 1 godz./błąd. Warto o tym czasem pomyśleć.
<hr size=1 noshade>Zarządzanie projektami informatycznymi - część 8
