Kategorie
Biznes Zarządzanie

Bugfixing. Kto powinien płacić za naprawianie błędów?

Każde oprogramowanie ma błędy. Jednak kto finansowo odpowiedzialny jest za naprawę błędów w oprogramowaniu (bug fixing)? To pytanie, które często pojawia się w relacjach zamawiający–wykonawca.

Co to jest błąd?

Błąd (bug) jest nieoczekiwaną usterką oprogramowania, która przy założeniu pewnych warunków wstępnych powoduje, że aplikacja działa niewłaściwie.

Jak i kiedy powstają błędy?

Każde oprogramowanie ma błędy, które pozostają w ukryciu tak długo, dopóki nie zostaną odkryte.

Kto płaci za błędy?

Bardzo łatwo założyć, że błąd to pomyłka wykonawcy z winy wykonawcy. W przypadku oprogramowania sprawa nie jest jednak taka prosta. Często pojawia się brak zrozumienia ze strony zamawiającego, że naturą oprogramowania jest pojawianie się błędów w trakcie jego eksploatacji.

Dlaczego coś nie działa?

  • Ponieważ strony źle zdefiniowały wymagania?
  • Ponieważ zewnętrzna firma – partner, z którym współpracujemy, wprowadziła modyfikacje?
  • Ponieważ niepoprawnie zostały zdefiniowane warunki graniczne dla działania danej funkcji?
  • Ponieważ zespół Klienta źle zrozumiał działanie danej funkcji?

Płacimy za tworzenie oprogramowania, a ono ma błędy, dlaczego mamy płacić za błędy?

Płacimy za tworzenie oprogramowania, a rozliczacie nas za zarządzanie projektem i komunikację! Dlaczego mamy płacić za to, że z nami rozmawiacie?!

Jakie jest rozwiązanie?

Rozwiązaniem jest zrozumienie, że błędy są naturalną częścią tworzenia oprogramowania bez wyjątków. Będą występować również po samym wdrożeniu oprogramowania i tutaj pojawia się temat umów Utrzymaniowych (SLA, serwisowych) lub utrzymaniowo-rozwojowych.

Do czego służą umowy utrzymaniowo-rozwojowe?

Utrzymanie systemu IT polega na modyfikowaniu kodu źródłowego w celu:

  • eliminacji błędów programistycznych tzw. bugfixing (np. naprawa wyjątków);
  • naprawiania usterek;
  • optymalizacji kodu źródłowego (np. refactoring kodu w celu zwiększenia kompatybilności, uniwersalności, elegancji rozwiązania);
  • optymalizacji prędkości działania (np. refactoring kodu w celu zwiększania prędkości działania aplikacji);
  • poprawy bezpieczeństwa (np. instalacja nowych wersji oprogramowania);
  • adaptowaniu do zmieniającego się środowiska zewnętrznego (np. zmiany w zewnętrznych Web Service).

Źródła: