Jak uczenie maszynowe w połączeniu z dobrymi praktykami tworzenia kodu wpływają na jakość, czyli...

Jarosław Hryszko

Pole bitwy

� System kluczowy dla produkcji pojazdów

� 10 wydań do tej pory� Ściśle określone ramy czasowe dla

przygotowania nowego wydania � Długie okresy wydań� Wydawany w technologii .NET� Waterfall

Wróg

Wersja 10: 716 wykrytych defektów, w tym:

� 306 podczas testów systemowych

� 160 defektów krytycznych

� 83 retesty zakończone niepowodzeniem

Następstwa

� Dążenie do podniesienia jakości

� Żądanie podniesienia jakości

� Wysokie koszty napraw defektów

� Rosnąca frustracjazespołu testerów

Napis głosi:„Uprzejmie prosimy kolegówprogramistów o podniesieniejakości tworzonej aplikacji”

Programiści: Mamy arsenał

doskonałej broni...

...ale nie wiemy gdzie strzelać....

A czas nie jest z gumy!

Plan!

Rozpoznanie

• Wykorzystanie wersji 10 do procesu uczenia maszynowego• Predykcja obszarów defektogennych w kodzie

dla nowej wersji 11

Działanie

• Zastosowanie najlepszych praktyk przez zespół programistów w pierwszej kolejności we wskazanych obszarach

Weryfikacja

• Sprawdzimy, czy to coś dało• ...a jeśli tak, to będziemy się tym chwalić

A.I. wkracza do akcji

Zebranie danych

• Miary kodu• Log repozytorium• Defekty

Niezrówno-ważenie

klas• SMOTE

Wybór cech• Twórczość

własna

Uczenie maszynowe

• Random Forest

Wynik predykcji

Refaktoryzacja

Przepisanie kodu z zastosowaniem poniższych technik;Reguła skauta

Zasady SOLID

Zasada jednej odpowiedzialności;Zasada otwarte –zamknięte;Zasada podstawienia LiskovZasada segregacji interfejsówZasada odwrócenia zależności

Testy

Testy jednostkowe orazTest Case-Driven DevelopmentTester pisze przypadek testowy, testujący krytyczną funkcjonalnośćProgramista pisze kod tak, aby test się udał

Programiści wytaczają działa

Wzorce projektowe

Kreacyjne: Fabryka, SingletonStrukturalne: Pełnomocnik, Dekorator, FasadaCzynnościowe: Łańcuch zobowiązań, Polecenie, Strategia

Pryncypia architekturalne

Zgodność ze standardami organizacjiAutonomiczne, bądź słabo zależne od zewnętrznych modułówReguła KISSBrzytwa OckhamaWydajność, bezpieczeństwo, przenaszalność

Przeglądy kodu

Dzielenie się wiedząŚwieże spojrzenieOgranicza konfliktyUnikanie błędów (szczególnie związanych z wymaganiami)

Wyniki?

Wyniki!

Defekty w. 10 w. 11 Ró żnica

Krytyczne 162 56 -65%

Duże 188 101 -48%

Średnie 248 152 -38%

Małe 200 110 -45%

Wykryte podczastestów systemowych

306 93 -70,60%

Retesty zako ńczone niepowodzeniem

83 23 -72,30%

Przypadki wsparcia

Testy wydajności

1 2 3 4 5 6

Defekty związane z wydajnością

Defekty wykryte podczas testów wydajno ściowych

w. 10 w. 11

Krytyczne 4 0Duże 1 1Średnie 2 2Małe 1 0

Koszt zapewnienia jakości

Programowanie Testowanie Po wydaniu Całkowite QA

Koszt wdrożenia predykcji

Element Potrzebny czas

Pozyskanie narzędzia DePress 0 h

Szkolenie 4 h

Zebranie danych 3 h

Przygotowanie predykcji 1 h

RAZEM 8 h

www.defectprediction.net