Ile czasu należy poświęcić na błędy w porównaniu do oryginalnego rozwoju? [Zamknięte]

To pytanie jest trochę abstrakcyjne, ale mam nadzieję, że ktoś wskaże mi właściwy kierunek.

Moje pytanie brzmi: ile czasu można poświęcić na błędy w projekcie oprogramowania w stosunku do pierwotnego czasu programowania. Zdaję sobie sprawę, że istnieje ogromna liczba czynników determinujących, ale liczyłem na typowy lub średni podział.

Na przykład, jeśli projekt A zajmuje 40 godzin, a dodatkowe 10 błędów naprawczych, wówczas ten projekt miałby stosunek 4: 1.

Jeśli inny projekt (B) zajmie 10 godzin, ale kolejne 8 błędów, to będzie miał stosunek 5: 4.

Czy to udokumentowana / zbadana koncepcja?

AKTUALIZACJA

Dziękuję za wszystkie pouczające odpowiedzi. Rozumiem, że ze względu na wszystkie zmienne i czynniki środowiskowe niemożliwe jest ustanowienie standardu dla tego rodzaju wskaźników. Zanim przydzielę odpowiedź, chciałbym wiedzieć, czy ta metryka ma uzgodnioną nazwę, dzięki czemu mogę przeprowadzić dalsze badania. Chciałbym przejść do punktu, w którym mogę zrozumieć pomiary niezbędne do samodzielnego wygenerowania metryk i ostatecznie opracować podstawowy standard dla mojego projektu.

Równowaga procentowa całkowitej pojemności przypisanej do naprawy defektów jest równa szybkości wstrzykiwania defektów .

Oczywiście na ten wskaźnik może wpływać wiele czynników, między innymi: jaki produkt opracowuje zespół, jakie technologie i praktyki techniczne stosują, poziom umiejętności zespołu, kulturę firmy itp.

Biorąc pod uwagę Zespół B, jeśli stworzą średnio 8 jednostek przeróbki na każde 10 jednostek pracy, którą wykonają, wówczas praca tych 8 jednostek stworzy nowe 6,4 jednostek przeróbki. Możemy oszacować całkowity wysiłek, jaki ostatecznie będą musieli ponieść, jako sumę postępu geometrycznego:

10 + 8 + 6,4 + 5,12 + ...

Liczba błędów spadnie wykładniczo z czasem, ale Drużyna B ma taki współczynnik w swoim wykładniku, że bardzo powoli spada do zera. W rzeczywistości suma pierwszych trzech terminów z powyższych serii wynosi tylko 24,4; z pierwszych pięciu 33,6; z pierwszych 10, 45; z całej serii, 50. Tak więc podsumowanie zespołu B: szybkość wtrysku wady, 0,8; rozwój funkcji, 10/50 = 20%; usuwanie wad, 80%. 20/80 to ich trwała alokacja zdolności.

Natomiast Drużyna A jest w znacznie lepszej formie. Ich postęp wygląda następująco:

40 + 10 + 2,5 + 0,625 + ...

Suma tej serii wynosi 53 1/3, więc przydział rozwoju funkcji dla Drużyny A wynosi 40 / (53 1/3) = 75%, a przydział naprawiania wad wynosi 25%, co odpowiada współczynnikowi wstrzykiwania wad na poziomie 10/40 = 0,25 .

W rzeczywistości wszystkie warunki w serii Drużyny A po pierwszych trzech są pomijalnie małe. W praktyce oznacza to, że Zespół A prawdopodobnie może zmiażdżyć wszystkie swoje błędy kilkoma wydaniami serwisowymi, przy czym drugie wydanie jest dość niewielkie. Stwarza to również złudzenie, że każdy zespół może to zrobić. Ale nie Drużyna B.

Myślałem o tej równoważności, czytając nową książkę Davida Andersona „Kanban” . (Książka jest na inny temat, ale dotyczy również problemów związanych z jakością.) Omawiając jakość oprogramowania, Anderson cytuje tę książkę autorstwa Capers Jones, „Oceny oprogramowania, testy porównawcze i najlepsze praktyki” :

„… w 2000 r.… zmierzona jakość oprogramowania dla zespołów z Ameryki Północnej… wahała się od 6 defektów na punkt funkcji do mniej niż 3 na 100 punktów funkcji, zakres od 200 do 1. Punkt środkowy to około 1 defekt na Od 0,6 do 1,0 punktów funkcyjnych. Oznacza to, że drużyny często spędzają ponad 90 procent swoich wysiłków na usuwaniu błędów. ”Przytacza przykład podany przez jednego z jego kolegów z firmy, który spędza 90% czasu na naprawianiu błędów .

Płynność, z jaką Anderson jedzie z szybkością wtrysku defektu do alokacji zdolności defext mocowania ( popyt awaria jest określenie dla niego) sugeruje, że równoważność tych dwóch rzeczy jest dobrze znany jakości naukowców oprogramowania i prawdopodobnie były znane od jakiegoś czasu .

Kluczowe słowa w rozumowaniu, które próbuję tu przedstawić, to „równowaga” i „zrównoważony”. Jeśli zabierzemy zrównoważony rozwój, istnieje oczywisty sposób na oszukiwanie tych liczb: wykonujesz wstępne kodowanie, następnie przechodzisz do kodowania gdzie indziej i pozostawiasz konserwację innym. Lub zaciągniesz dług techniczny i zwolnisz go na nowego właściciela.

Oczywiście żaden konkretny przydział nie będzie pasował do wszystkich drużyn. Jeśli zadeklarujemy, że 20% musi zostać wydane na błędy, wtedy, jeśli zespół ma bardzo niski wskaźnik wstrzykiwania defektów, po prostu nie będzie miał wystarczającej liczby błędów, aby wypełnić czas, a jeśli zespół miał bardzo wysoką stawkę, ich błędy będzie się nadal kumulować.

Zastosowana tutaj matematyka jest znacznie uproszczona. Zlekceważyłem takie rzeczy, jak koszty transakcji (spotkania planistyczne i szacunkowe, sekcje pośmiertne itp.), Które mogłyby nieco wpłynąć na procent. Pominąłem również równania symulujące utrzymanie jednego produktu i jednoczesne rozwijanie innego. Ale wniosek nadal się utrzymuje. Zrób, co możesz, pod względem praktyk technicznych, takich jak testy jednostkowe, ciągła integracja, przeglądy kodu itp., Aby zmniejszyć wskaźnik wstrzykiwania defektów, a w konsekwencji popyt na awarie. Jeśli możesz utworzyć tylko jeden błąd na każde 10 funkcji, będziesz mieć dużo wolnego czasu na opracowanie nowych funkcji i zadowolenie klientów.

Niestety uważam, że stosunek ten jest bardzo zmienny w danym projekcie. Będzie to miało drastyczny wpływ na twoje środowisko, język, narzędzia, wielkość zespołu i doświadczenie.

Powinieneś spędzać czas na błędzie tylko wtedy, gdy zyski z poprawki są większe z inwestycji.

Użyj poniższej matrycy (poziomo - czas potrzebny na naprawę błędu, pionowo - rodzaj błędu - wpływ na użytkowników)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Przykład problemów:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

Matryca może być bardziej złożona z różnymi poziomami dotkliwości, wysiłku, ryzyka itp

Możesz nawet utworzyć rangę dla każdego błędu i naprawić je na podstawie rankingu. Coś jak:

Bug priority = Risk x Severity x Effort

* Może być (1-x) dla niektórych operandów, w zależności od wybranej skali :)

Tak więc, aby odpowiedzieć na twoje pytanie: zależy od rodzaju błędów, dostępnego czasu / budżetu itp.

Jest bardzo zmienny, nie tylko (oczywiście) pod względem doświadczenia i jakości zespołu oraz trudności projektu (to nie to samo, tworząc inną standardową aplikację internetową niż nowe jądro systemu operacyjnego), ale także podejście do zarządzania Użyję.

Na przykład w modelu kaskadowym możesz precyzyjnie ustawić pierwszy błąd w pierwszej fazie testowania, ale w środowisku zwinnym może być trudne podniesienie linii z napisem „odtąd poprawiamy błędy”, ponieważ funkcje mogą się zmieniać ( i dla mnie niesprawiedliwe jest uznawanie zmiany funkcji za błąd)

Z doświadczenia mówię, że jest to ZAWSZE niedoceniane i bardzo łatwo może spędzić tyle samo godzin, co „oryginalny projekt”.

Naprawdę poprawna odpowiedź to zero godzin na poprawki błędów, ponieważ Twój kod jest doskonały. :-)

Realistycznie rzecz biorąc, nie mogę powiedzieć, że kiedykolwiek słyszałem, że ktoś prosi lub oferuje tego rodzaju proporcje. Nie oznacza to, że niektóre firmy nie śledzą czasu zarówno na rozwój, jak i utrzymanie. Jednak opracowanie aplikacji jest tak krótkie w porównaniu z konserwacją, że większość firm nie wraca i nie oblicza tego współczynnika. Prawdopodobnie bardziej martwi ich wiedza o tym, dlaczego aplikacja wymaga konserwacji i zastosowanie tych ustaleń do nowych aplikacji.

Zbyt szerokie kryterium błędu może prawie podwoić Twój czas. Nadgorliwy menedżer, który uważa, że ​​prośba klienta o powiększenie przycisku (mają problemy z myszą), to świetny sposób na zwiększenie liczby naprawionych przez nas błędów. Naprawienie zajmie tylko kilka sekund, ponieważ nie ma potrzeby rozważania, testowania, ponownej kompilacji i dystrybucji poprawki. Och, i to jest podwójnie liczone jako nowa funkcja.

Najważniejszym czynnikiem decydującym o tym jest to, czy pracujesz z nową technologią, czy z istniejącą. Jeśli pracujesz z czymś nowym i opracowujesz coś, co nie zostało zrobione lub zostało zrobione kilka razy w różnych okolicznościach, poświęcisz dużo czasu na poprawki błędów i doprowadzenie projektu do działania tak, jak chcesz . Często błędy będą wynikiem pracy w kącie i będziesz musiał wykonać znaczną ilość pracy, aby zrestrukturyzować to, co zrobiłeś. Ponadto wiele błędów będzie wynikać z niepełnego zrozumienia oczekiwań użytkowników i nieświadomości deweloperów dotyczących przypadków skrajnych.

Jeśli pracujesz nad ustaloną technologią, większość problemów zostanie rozwiązana przez biblioteki lub praktyki w społeczności i powinieneś być w stanie google, kupić lub poprosić o wyjście z błędów, które napotkasz.

Na krytycznym oprogramowaniu stosunek 1: 1 nie jest niczym niezwykłym. W przypadku samych testów jednostkowych zauważyłem, że wskaźniki wspominają 1 dzień testów jednostkowych na każde 10 wierszy kodu.

Myślę, że to pytanie jest stronnicze: zaczyna się od założenia, że ​​poprawianie błędów jest fazą podobną do rozwijania nowych funkcjonalności . Nie o to chodzi.

Dobry programista nie poświęci dużo czasu na debugowanie kodu, ponieważ jego kod będzie od samego początku wolny od błędów. Zły programista poświęci dużo czasu na debugowanie swojego kodu, ponieważ nie może tworzyć odpowiednich abstrakcji, aby rozwiązać prawdziwe problemy.

Należy pamiętać, że programiści powinni sami przetestować własny kod. Ich zadaniem jest dostarczanie kodu wolnego od błędów. Trudno więc oddzielić kodowanie od debugowania.

To także kwestia pierwszeństwa. Podczas opracowywania czas niezbędny do naprawy błędu jest wykładniczo związany z czasem, który upłynął od momentu wstawienia błędu do kodu. Dlatego poprawianie błędów powinno mieć wyższy priorytet niż opracowywanie nowych funkcjonalności.

Zamiast mówić o „czasie poświęcanym na błędy”, powinieneś mówić o „czasie poświęcanym na testy” (testy integracyjne, testy akceptacyjne użytkownika ...)

Myślę, że masz rację - nie dostaniesz żadnych sensownych danych ze względu na mniejszą liczbę wpływających czynników.

Jeśli to pomoże, mogę powiedzieć, że projekty, nad którymi pracuję (przestrzeń korporacyjna, duże złożone systemy, dużo integracji z innymi systemami) mają stosunek około 3: 2. Większość z nich nie jest błędami w kodzie - częściej błędy w interfejsach. Na przykład, system A i B rozmawiają ze sobą poprzez interfejs X. Twórcy systemu A interpretują interfejs X nieco inaczej niż twórcy systemu B. Następuje komedia.

Należy zauważyć, że opracowanie kodu i testowanie / poprawianie błędów kodu nie powinny być dwiema odrębnymi fazami. Jeśli testujesz w miarę rozwoju, koszt naprawiania błędów jest mniejszy.

Biorę czysto praktyczny punkt widzenia: co jeszcze bardziej ogranicza praktyczną użyteczność projektu? Jeśli jest to błąd w istniejącej funkcjonalności, powinieneś naprawić błędy. Jeśli brakuje jej funkcji, powinieneś pierwotnie opracować, a następnie wrócić i naprawić błędy po zaimplementowaniu najpoważniejszych brakujących funkcji. Wymaga to znajomości przypadków użycia. Błąd, który powoduje awarię programu w niektórych dziwnych przypadkach narożnych, może mieć niższy priorytet niż niewielkie ulepszenia użyteczności, które wpływają na wszystkich. Mały uciążliwy błąd w najczęściej używanej funkcjonalności może być ważniejszy niż funkcja, która przynosi korzyści tylko osobom, które popychają twoje oprogramowanie do granic możliwości.