Czy naprawienie błędu na końcu projektu jest znacznie droższe?

W poście na blogu autorstwa Andrew Haya postawiono następujący aksjomat:

Naprawienie błędu na końcu projektu kosztuje znacznie więcej niż naprawienie tego samego błędu wcześniej w projekcie.

Nie wydaje się to jednak pewne, zwłaszcza po przeczytaniu postu na blogu o Less Wrong , a dane, które widziałem, aby to zrobić, są bardzo stare.

Czy ten aksjomat jest dziś dokładny?

Jedyne twarde dane, jakie kiedykolwiek widziałem, to Boehm i Papaccio, zrozumienie i kontrola kosztów oprogramowania .

Wynika to z 1988 roku i było badaniem około 80 projektów oprogramowania. Doszli do wniosku, że decyzja podjęta wcześnie i skorygowana z opóźnieniem może kosztować 50-200 razy więcej, niż miałaby, gdyby została wcześniej skorygowana. Ale o tych bardzo wczesnych decyzjach, o których mówią, należy wybrać system operacyjny, którego języka i bazy danych użyć.

Tak więc liczby te mogą być przewyższone dzisiejszym rozwojem oprogramowania. Jednak teraz mamy duże doświadczenie w tej dziedzinie i instynktownie wiemy, że jest to do pewnego stopnia prawdziwe.

W skrajnym przypadku wiemy, że jeśli uchwycono błąd w wymaganiach tuż przed przejściem do produkcji, powoduje to wiele przeróbek i opóźnia lub w rzeczywistości anuluje projekt, a jeśli został on wykryty przed wykonaniem jakiejkolwiek pracy, byłby w porządku.

Edycja: Doc Brown ma dobry punkt w swoim komentarzu.

Badania Boehm przeprowadzono w projektach COBOL i FORTRAN w czasach, gdy czasy kompilacji i uruchamiania były absurdalnie wolne. Swoją karierę rozpocząłem na początku lat 90. w COBOL, a cykl kompilacji i testów trwał tak długo, że warto było przetestować kod na sucho przed przejściem przez ten cykl (lub przynajmniej w fazie kompilacji, na wszelki wypadek możesz coś złapać i anulować wcześniej, oszczędzając sobie godzinę).

Z kolei nasi szefowie śmiali się z naszych skarg, ponieważ nie tak dawno musieli nieść pudełko ręcznie sortowanych kart perforowanych do serwerowni i zostawić je tam na jeden dzień.

To było zdecydowanie bardziej prawdziwe niż teraz.

A jednak bardzo niedawno widziałem blogi wykorzystujące wizualizację tego problemu przez Steve'a McConnella ( ref. , Datowana na 1996 rok), tak jakby wykres ten był oparty na twardych liczbach. To nie jest To wizualizacja, aby wyjaśnić jego punkt po prostu.

Myślę, że przesłanka Morendila w cytowanym artykule OP jest dobra. Nauka na ten temat jest słaba i nieaktualna, a jednak traktowana jak kanon. Ale myślę też, że dobrze sobie radzi i brzmi prawdziwie, ponieważ z gorzkiego doświadczenia wiemy, że nadal jest to prawda, przynajmniej do pewnego stopnia. I myślę, że jego dramatyczne sformułowanie „chora dyscyplina” nie sprzyja mu.

Choć nie jestem świadomy dowolnego dysku danych lub innych dowodów na poparcie tego twierdzenia, na minimum , ja figura to jest zdrowy rozsądek.

Pomyśl o tym w ten sposób .. Jeśli masz złożony system z wzajemnie zależnymi podsystemami (jak większość nie-trywialnych aplikacji), zastanów się nad problemami domieszkowanymi, które mogą być wynikiem zmian wprowadzonych w dowolnym systemie. Jeśli okaże się, że podsystemy są poprawne (poprzez testy jednostkowe i tym podobne) i zostały naprawione wcześnie, liczbę błędów, które zostaną spowodowane z powodu samych domniemań , można zmniejszyć, po prostu naprawiając je wcześniej.

Ponadto, jeśli naprawiasz błędy wcześnie, implementacja jest wciąż świeża w głowie dewelopera. W zależności od długości danego projektu, jeśli naprawiasz błędy na końcu, programista będzie musiał poświęcić czas na zastanowienie się, co napisali i (być może), w jaki sposób działają podsystemy, od których zależy ich kod. Czas poświęcony na naukę tego = $.

Wątpię, aby w ogóle można było wymyślić naukowo sztywny sposób zmierzenia tego - w grę wchodzi po prostu zbyt wiele innych czynników i żadne dwa projekty nie są na tyle porównywalne, by służyć jedynie jako studia przypadków. Jednak logiczne myślenie powinno dać ci długą drogę. Kilka argumentów:

• Całkowita ilość kodu w projekcie zwykle rośnie pod koniec. Im dłużej czekasz na naprawienie błędu, tym większa baza kodów, którą musisz dotknąć.
• Jakość nowego kodu dodawanego do projektu zmniejsza się pod koniec, przynajmniej jeśli pojawia się presja (co zwykle jest dane): zbliżający się termin sprawia, że ​​ludzie wyrzucają najlepsze praktyki za burtę, aby wysłać je na czas. Oznacza to, że im później naprawisz błąd, tym więcej złego kodu musisz przesiać.
• Mimo, że powielanie kodu jest generalnie niezadowolone, zdarza się to cały czas, a ponieważ łatwo kopiować-wklejać, ale trudno ponownie scalić zduplikowane sekcje kodu, ilość raz wklejonego kodu zwykle wzrasta w trakcie życia projekt. Więcej wklejonych kodów oznacza większą szansę, że twój błąd zostanie zduplikowany i będzie musiał zostać znaleziony i naprawiony kilka razy (w konsekwencji większa szansa, że ​​niektóre jego wystąpienia pozostaną niezauważone).
• Naprawienie błędu to zmiana w bazie kodu; macie nadzieję, że wszystko się poprawi, ale zmiana zawsze wiąże się z ryzykiem. Zmiana, która powoduje poważne problemy w projekcie z upływem miesięcy, powinna pozostawić dużo miejsca na zarządzanie szkodami, ale dwa dni przed wysyłką masz poważne kłopoty.
• Im dłużej sam błąd istnieje, tym bardziej prawdopodobne jest, że inne części aplikacji zaczną polegać na jego złym zachowaniu. Następnie, gdy to naprawisz, nagle uwalniasz kilka wtórnych błędów w kodzie, które nie oczekują, że twoja funkcja rzeczywiście zapewni poprawne udokumentowane wyniki.

Jest to podstawowa akceptowana rzecz z inżynierii systemów - i dotyczy każdej formy rozwoju technicznego (czy to budowania mostów, pocisków, pancerników czy oprogramowania).

Zasadniczo koszt rzeczy rośnie w przybliżeniu o rząd wielkości, gdy przechodzisz przez etapy rozwoju.

Coś, co kosztuje 10 USD do rozwiązania w momencie wymyślenia pomysłu ...

Kosztuje około 100 USD, jeśli musisz przejść do aktualizacji specyfikacji ....

Lub kosztują około 1000 USD, jeśli coś zostało zaimplementowane i musisz wprowadzić zmiany w tym momencie (i zaktualizować specyfikację, uzyskać zatwierdzenia itd.), Ale nie przeszło przez to formalnego testu akceptacji / wyprzedaży

Lub koszt około 10000 USD, jeśli coś zostało wdrożone i klient zaakceptował, i musisz wprowadzić zmiany w tym momencie (i zaktualizować specyfikację, uzyskać zatwierdzenia oraz ponownie przetestować i ponownie uruchomić akceptację i kwalifikacje klienta itd.)

A koszt po wdrożeniu / wdrożeniu / oddaniu do użytku jest jeszcze większy.

Przykładów jest mnóstwo i łatwo je zrozumieć: system bankowy z poważną zmianą zakresu wprowadzoną po skorzystaniu z niego 25 000 pracowników będzie kosztował pakiet w czasie ponownego szkolenia ... zanim jeszcze rozważysz określanie zakresu, kodowanie, testowanie, regresję, etc etc itd.

OCZYWIŚCIE twój przebieg będzie się różnił: koszty i skutki zmiany strony internetowej e-commerce Freda Nurke'a z elektronicznym ogrzewaniem skarpet są nieco inne niż koszty zmiany oprogramowania na komputerze sterującym lotem.

Nie mam dostępu do twardych danych ani faktów, dlatego mogę jedynie przedstawić anegdotyczne spostrzeżenia zebrane podczas ostatnich 20 lat pracy w branży IT.

Uważam, że istnieje ogromna różnica między sposobem, w jaki większość programistów tworzy dziś oprogramowanie, w porównaniu do 20 lat temu. Ponieważ ruch Agile nabrał tak dużego rozpędu, szczególnie w ciągu ostatnich 5-6 lat, zaobserwowałem prawdziwą zmianę postaw w miejscu pracy. Tak bardzo, że jakość tego, co robimy, wydaje się rosnąć skokowo z każdym rokiem, a wraz z każdym projektem, gdy wykorzystujemy wnioski wyciągnięte z projektu do projektu. Uproszczone procesy w połączeniu z naciskiem na rozwój w pierwszej fazie testów stały się bardzo kontrowersyjne i stały się powszechne. Do tego stopnia, że ​​wchodząc dzisiaj do wielu firm, jeśli nie czujesz się dobrze z Agile, będziesz mieć szczęście, jeśli nie pokażą ci drzwi.

Jaki miał to wpływ. Przede wszystkim zauważyłem, że problemy często identyfikowane są znacznie wcześniej. Często zdarza się, że jeśli problem nie wydaje się zbyt duży, czasami można go odłożyć na czas nieokreślony. W rzadkiej garstce przypadków widziałem, że błędy, które uważano za trywialne, stają się poważnymi problemami, gdy zostaną rozwiązane później, ponieważ niektóre podstawowe kwestie stają się oczywiste, które nie były wówczas rozpatrywane. Czasami może to prowadzić do wyciągnięcia cyklu napraw, co może być do pewnego stopnia kosztowne, ale koszt ten jest często mierzony mniej pod względem zasobów, a częściej pod względem wpływu na relacje między klientem a deweloperem. Klienci przyzwyczajają się do tego zwinnego sposobu myślenia, który zwraca im wyniki znacznie szybciej niż w dawnych czasach, dzięki wysoce iteracyjnym sprintom programistycznym i szybkiemu przetwarzaniu wniosków i implementacji, więc oni oczekują od nas wielu. Jeśli chodzi o rzeczywiste błędy, czas na naprawienie błędu jest znacznie znacznie skrócony w wyniku posiadania solidnego zestawu testów do obsługi zmian oraz możliwości tworzenia nowych testów, na podstawie których można uzyskać wgląd i rozwiązania do zgłoszonych problemów.

Ogólnie rzecz biorąc, wydaje się, że ogólny wysiłek w celu naprawienia błędów został w większości przypadków zmniejszony, jeśli istnieje solidny zestaw testów i procedur zapewniających, że testowanie pozostaje w centrum uwagi tego, co robi programista, ale rzeczywisty koszt w pewnym sensie przeniosło się częściowo z wdrożenia na inne obszary działalności, ponieważ w pewnym sensie skupiono się również na czystej podaży i popycie na zarządzaniu relacjami.

Inną rzeczą, która stała się oczywista, jest to, że nasze instynkty jelitowe sprzed kilku lat, które sugerowały, że zwinność skróci nasze cykle konserwacji, zostały udowodnione w pewnym stopniu zarówno dobrze, jak i źle. W tym sensie, że rzetelne testowanie ułatwiło debugowanie i naprawę naszego kodu w dużym stopniu, a także w celu zmniejszenia ogólnej liczby błędów opublikowanych w kodzie produkcyjnym, i źle, w tym sensie, że teraz pracujemy ciężej, aby uniknąć konieczności zachowujemy starszy kod, stale zmieniając kod i ulepszając architekturę, tak że coraz rzadziej musimy opracowywać nowe produkty całkowicie od zera.

A więc w końcu, co to oznacza w odniesieniu do pytania PO? Cóż, oznacza to, że odpowiedź naprawdę nie jest tak wycięta i sucha, jak moglibyśmy kiedyś sądzić. 15 lat temu prawdopodobnie odpowiedziałbym na to pytanie tak, ale teraz uważam, że bardziej realistyczne jest stwierdzenie, że naprawdę trudno jest zmierzyć empirycznie, ponieważ natura tego, co robimy, aby opracować oprogramowanie, zmieniła się znacznie od czasu, kiedy zaczęliśmy zadawać sobie pytanie OP. W pewnym sensie, im bardziej rozwijamy nasze techniki i umiejętności w branży, tym bardziej pytanie rośnie od ostatecznego tak, do momentu, w którym podejrzewam, że za kilka lat będziemy mówić, że to nie ma znaczenia kiedy naprawimy błędy, ponieważ nasze testy i procesy będą o wiele bardziej niezawodne, że czas naprawiania błędów będzie mniej zależny od wysiłków zmierzających do oszczędzania naszych budżetów, a bardziej od priorytetów zaspokajających potrzeby naszych klientów, a względny koszt będzie stają się praktycznie bez znaczenia kontekstowo.

Ale, jak mówię, nie są to dowody oparte na twardych danych, tylko moje obserwacje z ostatnich kilku lat i moje przeczucie mówiące, że będzie więcej wstrząsającej wiedzy, która poprawi sposób, w jaki robimy różne rzeczy.

Wczesne błędy będą się rozprzestrzeniać na inne części systemu, więc po naprawieniu błędu możesz zostać zmuszony do przepisania niektórych części systemu, które polegały na samym błędzie.

Z biegiem czasu będziesz się zastanawiać, jak zbudowane są niektóre części programu i będziesz musiał sobie przypomnieć. To jakaś forma długu technicznego (jeśli spieszycie się z projektem na wczesnym etapie, będziecie mieli problemy z jego ukończeniem z powodu przyjętych skrótów).

To takie proste i nie ma nic do udowodnienia.

Myślę, że starasz się przyspieszyć projekt tak szybko, jak to możliwe, aby przedstawić pracownikowi jakieś działające rozwiązanie. Dobrą wiadomością jest to, że będziesz mieć to bardzo szybko, złą wiadomością jest to, że prawdopodobnie nigdy nie skończysz tego bez całkowitego przepisania, jeśli tylko będziesz pisać bzdury tak szybko, jak to możliwe i planujesz naprawić wszystko w ciągu kilku miesięcy. Prawdopodobnie nawet nie będziesz w stanie tego refaktoryzować.

Cóż, prawdopodobnie nie mogę dać ci ostatecznego dowodu, o który prosisz, ale mogę opowiedzieć dość niedawny incydent z mojej pracy.

Dodaliśmy funkcję, która zapewniła możliwości zarządzania przepływem pracy do naszego produktu. Typowe rzeczy BDUF, specyfikacje podpisane i zatwierdzone przez klienta. Wdrożony do specyfikacji. Skargi od dnia 1 dotyczące wdrożenia.

Nie przeprowadziliśmy prawdziwego przeglądu użyteczności z klientem, po prostu uwierzyli na to, czego chcieli. Wynik: setki godzin przeróbek - analiza, projekt, wdrożenie i kontrola jakości musiały zostać przerobione. Wszystko dlatego, że specyfikacja pominęła konkretne przypadki użycia. Błąd w specyfikacji, jeśli chcesz.

Widziałem podobne rzeczy we wcześniejszych pracach, gdy ktoś w łańcuchu przyjmuje założenia odmienne od założeń użytkownika końcowego. Bezpośrednie błędy w kodowaniu są stosunkowo łatwe do rozwiązania, jeśli zostaną złapane blisko, kiedy się pojawią, ale błędy projektowe mogą zabić całe systemy.

Jeśli naprawisz błąd po wydaniu, wtedy będziesz musiał znaleźć i naprawić błąd - co może, ale nie musi zająć więcej czasu / kosztu, aby zrobić po wydaniu. Masz jednak do czynienia z testami integracji, testami regresji, testami UA, działaniami związanymi z wydaniem itp., Które należy uwzględnić. O ile poprawka błędu nie pojawi się wraz z kilkoma innymi poprawkami lub aktualizacją wersji, poniesiesz dodatkowy koszt za działania związane z testowaniem i wydaniem, których można by uniknąć, włączając poprawkę w początkowej wersji - ponieważ koszty te zostaną podzielone na wiele poprawki / aktualizacje / funkcje.

Weź również pod uwagę koszt, jaki błąd spowoduje w użyciu, jeśli jest to po prostu efekt kosmetyczny, to prawdopodobnie nie ma to znaczenia, ale błąd funkcji lub wydajności może spowodować koszty związane z działaniami wsparcia lub zmniejszoną produktywnością lub nieprawidłowymi obliczeniami.

Zapytaj Intela, ile kosztuje ich błąd Pentium, rakieta Ariane 5 to kolejny dobry przykład. Te błędy zostały naprawione na końcu projektu. Pracowałem nad systemem, w którym „próba” wydania oprogramowania ma budżet 6 cyfr. W tych ekstremalnych przypadkach łatwo jest zobaczyć koszt. W innych (najbardziej?) Przypadkach hałas ukrywa koszt, ale nadal tam jest.

Nie ma wątpliwości, że robaki kosztują pieniądze, dopóki istnieją. Jeden element, raporty Defektów, poświęca czas na kompilację, segregowanie i zamykanie jako duplikat, czas to pieniądz - dlatego otwarty błąd generuje ciągły koszt. dlatego musi być tak, że odroczenie naprawiania błędów kosztuje więcej niż naprawienie ich wcześniej.

Jeśli błąd ucieka w dziczy, koszt ma skok krokowy ...... Czy „Koniec projektu” przed lub po wydaniu oprogramowania?

Kiedyś przeczytałem artykuł, który miał dwa ciekawe punkty (niestety odniesienia, które miałem, dawno już minęły, więc będę musiał tutaj postulować). Pierwszą kwestią, którą podnieśli, było to, że około 50% wszystkich błędów zostało wprowadzonych do specyfikacji wymagań i że około 90% wszystkich błędów wykryto podczas testów UAT lub systemu.

Drugą kwestią, którą mieli, było to, że dla każdej fazy w modelu V koszt zwiększono 10-krotnie. Niezależnie od tego, czy czynnik jest poprawny, uważam, że jest on nieistotny, ale najbardziej kosztowne błędy mają miejsce, gdy projekt opiera się na błędnym założeniu. Prowadzi to do ogromnej ilości przepisywania. Cały kod, który działa z powodu tego założenia, ale nie powiedzie się, gdy zastosowane zostanie prawidłowe założenie, będzie musiał zostać przepisany.

Doświadczyłem konieczności przepisania całego modelu domeny z powodu jednego niepoprawnego założenia w specyfikacjach wymagań. Jeśli taki błąd zostanie wykryty wcześnie, to znaczy podczas przeglądania specyfikacji wymagań koszt jest bardzo niski. W tym konkretnym przypadku zajęłoby dziesięć linii tekstu. W przypadku, gdy zostanie stwierdzony podczas UAT (jak to było), koszt jest znaczny (w podanym przykładzie koszt projektu został zwiększony o 50%)

Brak danych statystycznych, ale osobiste doświadczenie:

Kod sterujący silnikiem rakietowym, nad którym pracowałem, miał taką linię powerCutoff = someCondition && debugOptions.cutoffIsAllowed;. Domyślna opcja nie była dozwolona. Ostateczna wersja miała usunąć wszystkie opcje debugowania, więc linia została zmodyfikowana na powerCutoff = someCondition;.

Czy złapałeś błąd podczas przeglądania kodu? Nie zrobiliśmy tego. Pierwszy przypadek wystąpienia warunku wyzwalającego w teście powodujący nieoczekiwane odcięcie miał miejsce zaledwie kilka miesięcy przed pierwszym lotem.

Ten błąd kosztowałby mniej niż godzinę, gdyby został wykryty podczas przeglądu. Może zostać kosztowany dzień lub dwa, jeśli zostanie złapany podczas integracji, co spowoduje pojedyncze powtórzenie testu. Jeśli zostanie złapany podczas formalnej kwalifikacji, może kosztować tydzień lub dwa, powodując ponowne uruchomienie pełnej serii testów z nową wersją.

W tej chwili koszt się podniósł. Najpierw zaprojektowaliśmy i przeprowadziliśmy testy, aby ustalić, czy jednostka lotnicza może nawet wywołać ten warunek. Po ustaleniu, że jest to realna możliwość, pojawił się koszt inżynierii, zarządzania i analizy klienta najlepszej poprawki, wydania nowej wersji, stworzenia i wykonania nowego planu testów regresji, testów systemu w wielu jednostkach i symulatorach. W sumie kosztuje tysiące, jeśli nie dziesiątki tysięcy roboczogodzin. Plus oryginalne 15 minut na faktyczną zmianę kodu.

Niestety, jak wiele rzeczy, to zależy.

Jeśli komunikat w oknie dialogowym jest błędnie napisany, poprawka może być „trywialna” (aktualizacja ciągu, przebudowa / pakiet, ponowne wdrożenie). Lub jeśli układ wymaga aktualizacji, modyfikacja pliku .css może być wystarczająca.

Jeśli błąd polega na tym, że wynik krytycznej metody, która ma ponad 100 stron specyfikacji i dowód jest nieprawidłowy, wówczas samo dochodzenie może potrwać kilka godzin lub dni. Do tego odnosi się stary „aksjomat” i to, między innymi, TDD i zwinny próbuje uniknąć (zawodzić wcześnie i wyraźnie, robić bezpieczny postępowy postęp, yada).

Z moich ostatnich doświadczeń z zespołami multi-scrum w ramach jednego projektu, „błędy” to zazwyczaj problemy ze scalaniem / integracją, które pojawiają się dopiero pod koniec wydania, gdy gałęzie funkcji są promowane do stabilnych. Są to najgorsze, ponieważ konflikty często wymagają wsparcia między zespołami, podczas gdy zespoły są w pośpiechu, aby osiągnąć swoje własne cele, ale nie wiem, że są droższe niż inne błędy, ponieważ pojawiają się, gdy występują: późno wydanie, ale najwcześniej mogą. To sprawia, że ​​są najgorsze.