Czy metodologia testowania oprogramowania opiera się na błędnych danych?

Powszechnie wiadomo w inżynierii oprogramowania, że ​​koszt naprawy błędu rośnie wykładniczo w miarę wykrycia błędu. Potwierdzają to dane opublikowane w Code Complete i dostosowane w wielu innych publikacjach.

Okazuje się jednak, że te dane nigdy nie istniały . Dane cytowane przez Code Complete najwyraźniej nie pokazują takiej korelacji kosztów / czasu rozwoju, a podobne opublikowane tabele pokazały korelację tylko w niektórych szczególnych przypadkach i płaską krzywą w innych (tj. Brak wzrostu kosztów).

Czy istnieją niezależne dane, które mogłyby to potwierdzić lub obalić?

A jeśli to prawda (tzn. Jeśli po prostu nie ma danych na poparcie tego wykładniczo wyższego kosztu późno wykrytych błędów), jak wpływa to na metodologię tworzenia oprogramowania?

Czy metodologia testowania oprogramowania opiera się na błędnych danych?

Tak, wyraźnie. Analiza krzywej zwinnego kosztu zmiany pokazuje, że część pracy Kenta Becka nad XP (nie jestem pewien, czy była to część jego motywacji, czy uzasadnienia) polegała na „spłaszczeniu krzywej” kosztów wad, w oparciu o wiedzę o „ krzywa wykładnicza ”leżąca za tabelą Code Complete. Tak więc, praca nad co najmniej jedną metodologią - tą, która najbardziej spopularyzowała tworzenie pierwszego testu - jest przynajmniej częściowo oparta na błędnych danych.

Czy istnieją niezależne dane, które mogłyby to potwierdzić lub obalić?

Tak, z pewnością są inne dane, na które możesz spojrzeć - największym badaniem, jakie znam, jest analiza wad przeprowadzona w Hughes Aircraft w ramach programu oceny CMM . Raport stamtąd pokazuje, w jaki sposób koszty defektów zależały od fazy dla nich : chociaż dane w tym raporcie nie zawierają odchyleń, więc musisz uważać na wyciąganie zbyt wielu wniosków „ta rzecz kosztuje więcej niż to”. Należy również zauważyć, że niezależnie od metodologii nastąpiły zmiany w narzędziach i technikach w latach 80. i dziś, które podważają zasadność tych danych.

Zakładając, że nadal mamy problem z uzasadnieniem tych liczb:

jak wpływa to na metodologię tworzenia oprogramowania?

Fakt, że polegamy na liczbach, których nie można zweryfikować, nie powstrzymał ludzi od robienia postępów na podstawie anegdot i doświadczenia: w ten sam sposób, w jaki uczy się wielu transakcji mistrz-uczeń. Nie wydaje mi się, żeby w średniowieczu istniał Journal of Evidence-Based Masonry , ale mimo to udało się zbudować całą masę dużych, imponujących i trwałych budynków z zauważalnym powodzeniem. Oznacza to, że naszą praktykę opieramy głównie na „tym, co zadziałało dla mnie lub ludzi, których spotkałem”; nic złego, ale być może nie najskuteczniejszy sposób na ulepszenie pola milionów ludzi, którzy stanowią kamień węgielny obecnego wieku technologicznego.

Rozczarowuje mnie to, że w tak zwanej dyscyplinie inżynieryjnej nie ma lepszych podstaw w empiryzmie i podejrzewam (choć wyraźnie nie mogę udowodnić), że moglibyśmy osiągnąć lepszy, wyraźniejszy postęp w ulepszaniu naszych technik i metodologii. ten fundament istnieje - tak jak wydaje się, że medycyna kliniczna została przekształcona przez praktykę opartą na dowodach. Opiera się to jednak na kilku dużych założeniach:

• że zastrzeżony charakter większości praktyk inżynierii oprogramowania nie uniemożliwia gromadzenia wystarczającej liczby użytecznych i odpowiednich danych;
• że wnioski wyciągnięte z tych danych mają ogólne zastosowanie (ponieważ inżynieria oprogramowania to zawód wykwalifikowany, osobiste różnice w doświadczeniu, umiejętnościach i smaku mogą mieć wpływ na taką możliwość);
• inżynierowie oprogramowania „w terenie” są w stanie i zmotywowani do wykorzystania uzyskanych w ten sposób wyników; i
• że tak naprawdę wiemy, jakie pytania powinniśmy zadać. Jest to oczywiście najważniejszy punkt tutaj: kiedy mówimy o ulepszaniu inżynierii oprogramowania, co chcemy poprawić? Jaki jest pomiar Czy poprawa tego pomiaru rzeczywiście poprawia wynik, czy też gra w system? Na przykład załóżmy, że kierownictwo mojej firmy zdecydowało, że zmniejszymy stosunek rzeczywistych kosztów projektu do przewidywanych kosztów projektu. Mógłbym po prostu zacząć pomnożyć wszystkie moje szacunki kosztów przez współczynnik krówki i osiągnąłem ten „cel”. Czy zatem powinno stać się standardową praktyką branżową fałszowanie wszystkich szacunków?

Z mojej strony odpowiedź na „jak wpływa to na metodologię tworzenia oprogramowania” brzmi „niewiele”.

Niezależnie od tego, czy zostanie złapany przez programistę czy użytkownika końcowego, czy potrzeba więcej pieniędzy, aby go naprawić po złapaniu przez użytkownika, czy nie, pozostaje faktem, że w systemie znaleziono błąd. Mam nadzieję , że jeśli zostanie złapany przez programistę, jest to szybka naprawa. Ta sama nadzieja dotyczy błędów wykrytych przez użytkownika.

Niezależnie od faktycznych godzin pracy programisty na naprawienie błędu wykrytego przez użytkownika końcowego, istnieje niematerialny koszt utrzymania stereotypu, że koderzy są do niczego. Gdy użytkownik znajdzie błąd, jest to wina programisty. Dlatego każdy błąd znaleziony przez użytkownika końcowego zmniejsza zaufanie użytkownika do systemu. To jak zwiedzanie domu, który chcesz kupić, i zobaczenie plamy po wodzie, która widać przez sufit w jednym z rogów domu. To samo w sobie jest łatwym rozwiązaniem, ale zastanawiasz się, co go spowodowało i co jeszcze mogło mieć wpływ na tę pierwotną przyczynę. Ile wart jest twój spokój? Być może będziesz musiał zburzyć ściany z powrotem do kołków i wizualnie sprawdzić wszystko, aby upewnić się, że plama pochodzi z izolowanego incydentu, który został naprawiony. Świadomość, że może to być możliwe, nie sprawia, że ​​czujesz się pewnie w domu. Podobnie,

Te koszty niematerialne są unikane, im szybciej błąd zostanie wykryty, co jest deklarowanym celem metodologii w stylu TDD. Błąd wykryty podczas pisania przez programistę lub partnera w parze, jeden wykryty podczas kompilacji lub jeden wykryty podczas testów jednostkowych / integracyjnych (warstwa dodana przez TDD), jest błędem, o którym użytkownik nigdy nie musi wiedzieć, że twój kierownik projektu nigdy nie musi przepraszać i że nie musisz być odciągany od tego, co robisz w tej chwili, aby przełączyć bieg w tryb naprawy usterek w części systemu, o której myślałeś, że pozostawiłeś za sobą tygodnie temu.

Przedmówię to faktem, że większość tego, co znajduję, pochodzi z lat siedemdziesiątych i wczesnych osiemdziesiątych. W tym czasie sekwencyjne modele procesów były znacznie bardziej powszechne niż podejścia iteracyjne i / lub przyrostowe (model spiralny lub metody zwinne). Wiele z tych prac opiera się na tych modelach sekwencyjnych. Nie sądzę jednak, by niszczyło to związek, ale jedną z korzyści podejścia iteracyjnego / przyrostowego jest szybkie uwalnianie funkcji (całego pionowego wycinka aplikacji) i rozwiązywanie problemów przed wstrzyknięciem zależności i złożonością każdej fazy jest wysoko.

Właśnie wyciągnąłem kopię Software Engineering Economics i znalazłem odniesienie do danych zawartych w tym wykresie w rozdziale 4. Przytacza „Projektowanie i kontrole kodu w celu ograniczenia błędów w rozwoju programu” autorstwa ME Fagana ( IEEE , PDF z UMD ), EB Daly's „Management of Software Engineering”, WE Stephenson's „Analiza zasobów wykorzystywanych w programowaniu oprogramowania Safeguard System Software” ( ACM ) oraz „kilka projektów TRW”.

... względny koszt korekty błędów oprogramowania (lub wprowadzenia innych zmian oprogramowania) w zależności od fazy, w której dokonywane są poprawki lub zmiany. Jeśli błąd wymagań oprogramowania zostanie wykryty i skorygowany podczas fazy planów i wymagań, jego korekta jest względnie prostą kwestią aktualizacji specyfikacji wymagań. Jeśli ten sam błąd nie zostanie naprawiony do fazy konserwacji, korekta obejmuje znacznie większy spis specyfikacji, kodu, instrukcji obsługi i konserwacji oraz materiałów szkoleniowych.

Ponadto późne korekty obejmują o wiele bardziej formalny proces zatwierdzania i kontroli zmian oraz o wiele szersze działania mające na celu ponowne sprawdzenie poprawności. Czynniki te łącznie powodują, że błąd zazwyczaj jest 100 razy droższy do skorygowania w fazie konserwacji w dużych projektach niż w fazie wymagań.

Bohem przyjrzał się również dwóm mniejszym, mniej formalnym projektom i stwierdził wzrost kosztów, ale o wiele mniej znaczący niż 100-krotny wzrost zidentyfikowany w większych projektach. Biorąc pod uwagę tabelę, różnice wydają się 4 razy większe, aby naprawić wadę wymagań po uruchomieniu systemu niż w fazie wymagań. Przypisał to mniejszej inwentaryzacji elementów składających się na projekt i zmniejszonej formalności, która doprowadziła do możliwości szybszego wdrożenia prostszego rozwiązania.

Oparta na Boehm in Software Engineering Economics, tabela w Code Complete jest raczej rozdęta (dolna granica zakresów jest często zbyt wysoka). Koszt wprowadzenia jakiejkolwiek zmiany w fazie wynosi rzeczywiście 1. Ekstrapolując z rysunku 4-2 w Software Engineering Economics, zmiana wymagań powinna wynosić 1,5-2,5 razy w architekturze, 2,5-10 w kodowaniu, 4-20 w testowaniu i 4 100 w konserwacji. Kwota zależy od wielkości i złożoności projektu, a także formalności zastosowanego procesu.

W załączniku E do Barry Boehm i Richarda Turnera Balansująca zwinność i dyscyplina zawiera niewielką część na temat empirycznych ustaleń dotyczących kosztu zmiany.

Pierwsze akapity cytują Extreme Programming Kent wyjaśnił, cytując Becka. Mówi, że jeśli koszty zmian rosną powoli w miarę upływu czasu, decyzje byłyby podejmowane możliwie późno i wdrażane byłyby tylko to, co było potrzebne. Nazywa się to „płaską krzywą” i to właśnie napędza programowanie ekstremalne. Jednak poprzednią literaturą była „stroma krzywa”, przy małych systemach (<5 KSLOC) o zmianie 5: 1 i dużych systemach o zmianie 100: 1.

Sekcja cytuje Centrum Inżynierii Oprogramowania na Uniwersytecie Maryland (sponsorowane przez National Science Foundation). Przeszukali dostępną literaturę i stwierdzili, że wyniki zwykle potwierdzają stosunek 100: 1, a niektóre wyniki wskazują na zakres od 70: 1 do 125: 1. Niestety były to zazwyczaj projekty „dużego projektu z góry”, którymi zarządzano w sposób sekwencyjny.

Istnieją przykłady „małych komercyjnych projektów Java” uruchamianych za pomocą Extreme Programming. Dla każdej historii śledzono wysiłek związany z naprawianiem błędów, nowym projektem i refaktoryzacją. Dane pokazują, że wraz z rozwojem systemu (wdrażanie kolejnych historii użytkowników) średni wysiłek zwykle rośnie w nie-trywialnym tempie. Wysiłek w refaktoryzacji wzrasta o około 5%, a wysiłki w kierunku ustalania nakładów - o około 4%.

Uczę się, że złożoność systemu odgrywa ogromną rolę w wymaganym nakładzie pracy. Budując pionowe przekroje przez system, spowalniasz tempo krzywej, powoli dodając złożoność zamiast dodając ją w stosy. Zamiast zajmować się masą złożoności wymagań, a następnie niezwykle złożoną architekturą, a następnie niezwykle złożoną implementacją itd., Zaczynasz bardzo prosto i dodajesz.

Jaki to ma wpływ na koszt naprawy? W końcu może niewiele. Ma jednak tę zaletę, że pozwala na większą kontrolę nad złożonością (poprzez zarządzanie długiem technicznym). Ponadto częste rezultaty często kojarzone z agile oznaczają, że projekt może zakończyć się wcześniej - zamiast dostarczać „system”, części są dostarczane do momentu zaspokojenia potrzeb biznesowych lub drastycznej zmiany w stosunku do nowego systemu (a zatem nowego projektu) jest potrzebne.

Metryki i modele Stephena Kana w inżynierii jakości oprogramowania mają rozdział w rozdziale 6 na temat opłacalności usuwania wad fazowych.

Zaczyna od cytowania artykułu Fagana z 1976 r. (Cytowanego także w Software Engineering Economics), aby stwierdzić, że przeróbki wykonane w projektowaniu wysokiego poziomu (architektura systemu), projektowaniu niskiego poziomu (projektowanie szczegółowe), a wdrożenie może być od 10 do 100 razy tańsze niż praca wykonana podczas testowania na poziomie komponentów i systemu.

Przytacza także dwie publikacje Freedmana i Weinberga z 1982 i 1984 r., Które omawiają duże systemy. Pierwszy to „Podręcznik solucji, inspekcji i przeglądów technicznych”, a drugi to „Recenzje, solucje i inspekcje”. Zastosowanie recenzji na wczesnym etapie cyklu programowania może zmniejszyć liczbę błędów, które docierają do faz testowania 10-krotnie. To zmniejszenie liczby wad prowadzi do obniżenia kosztów testowania o 50% do 80%. Musiałbym przeczytać badania bardziej szczegółowo, ale wydaje się, że koszt obejmuje również znalezienie i naprawę wad.

W badaniu z 1983 r. Przeprowadzonym przez Remusa, „Integrated Software Validation in View of Inspections / Review”, przeanalizowano koszty usuwania defektów na różnych etapach, w szczególności kontroli projektu / kodu, testów i konserwacji, z wykorzystaniem danych z Santa Teresa Laboratory IBM w Kalifornii. Cytowane wyniki wskazują na stosunek kosztów w wysokości 1:20:82. Oznacza to, że defekt wykryty podczas inspekcji projektu lub kodu ma koszt zmiany wynoszący 1. Jeśli ta sama defekt ucieknie do testowania, będzie kosztować 20 razy więcej. Jeśli ucieknie aż do użytkownika, podwoi koszt naprawy do 82. Kan, korzystając z przykładowych danych z firmy Rochester w Minnessocie, stwierdził, że koszt usunięcia defektu dla projektu AS / 400 jest podobny o 1:13:92. Wskazuje jednak, że wzrost kosztów może wynikać ze zwiększonej trudności ze znalezieniem usterki.

Wspomniane są publikacje Gilba z 1993 r. ( „Kontrola oprogramowania” ) i 1999 („Optymalizacja specyfikacji inżynierii oprogramowania i procesów kontroli jakości”) dotyczące kontroli oprogramowania w celu potwierdzenia innych badań.

Dodatkowe informacje można znaleźć na stronie Construx w temacie Wzrost kosztów defektów , który zawiera szereg odniesień do wzrostu kosztów naprawy defektów. Należy zauważyć, że Steve McConnell, autor Code Complete, założył i pracuje dla Construx.

Niedawno wysłuchałem przemówienia Real Software Engineering , wygłoszonego przez Glenna Vanderburga na konferencji Lone Star Ruby Conference w 2010 roku. Wygłosił to samo wystąpienie na szkockiej konferencji Ruby Conference i Erubycon w 2011 roku, QCon San Francisco w 2012 roku i O'Reilly Software Architecture Conference w 2015 r . Słuchałem tylko Konferencji Rubinowej Lone Star, ale rozmowa ewoluowała z czasem, gdy jego pomysły zostały dopracowane.

Venderburg sugeruje, że wszystkie te dane historyczne faktycznie pokazują koszt naprawy wad w miarę upływu czasu, niekoniecznie w miarę, jak projekt przechodzi przez kolejne fazy. Wiele projektów zbadanych we wspomnianych wcześniej artykułach i książkach było sekwencyjnymi projektami „wodospadu”, w których faza i czas poruszały się razem. Jednak podobny wzór pojawiłby się w projektach iteracyjnych i przyrostowych - jeśli defekt zostałby wstrzyknięty podczas jednej iteracji, naprawienie tej iteracji byłoby stosunkowo niedrogie. Jednak w miarę postępu iteracji dzieje się wiele rzeczy - oprogramowanie staje się bardziej złożone, ludzie zapominają o drobnych szczegółach dotyczących pracy w poszczególnych modułach lub częściach kodu, zmieniają się wymagania. Wszystko to zwiększy koszt naprawy wady.

Myślę, że jest to prawdopodobnie bliższe rzeczywistości. W projekcie wodospadu koszt wzrasta ze względu na liczbę artefaktów, które należy poprawić z powodu problemu z prądem. W projektach iteracyjnych i przyrostowych koszty rosną z powodu wzrostu złożoności oprogramowania.

To po prostu prosta logika.

Błąd wykryty w specyfikacji.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Jak widać, im później błąd zostanie wykryty, im więcej osób będzie zaangażowanych, tym więcej pracy trzeba wykonać ponownie, aw każdym „normalnym” środowisku praca papierkowa i biurokracja gwałtownie rosną po uderzeniu w UAT.

To wszystko bez uwzględnienia kosztów, jakie firma może ponieść z powodu błędu w oprogramowaniu produkcyjnym (utrata sprzedaży, nadmierne zamawianie, włamanie do klientów itp.)

Nie sądzę, aby ktokolwiek kiedykolwiek napisał nietrywialny system, który nigdy nie miał błędów w produkcji, ale wszystko, co możesz zrobić, aby wcześnie wykryć błędy, zaoszczędzi ci czasu i wysiłku na dłuższą metę. Przeglądy specyfikacji, recenzje kodu, obszerne testy jednostkowe, używanie różnych koderów do pisania testów itp. Itd. To sprawdzone metody wczesnego wykrywania błędów.

Wierzę, że dotyczy to i zawsze było związane z zarządzaniem ryzykiem i ekonomią. Jaki jest koszt zmniejszenia liczby wad w stosunku do bieżącej wartości wpływu przyszłych wad. Trajektoria żółtego ptaka znajdującego się nieco w Angry Birds nie jest równa trajektorii lotu rakiety Tomahawk podczas lotu. Twórcy oprogramowania w obu projektach nie mogą podejmować decyzji na podstawie tej tabeli. Pod tym względem nic się nie zmienia.

Myślę, że to działa w oparciu o informacje zwrotne, drogie błędy w terenie powodują, że firmy zaostrzają swoje procesy jakościowe, a brak skarg z zewnątrz powoduje, że firmy je rozluźniają. W miarę upływu czasu firmy opracowujące oprogramowanie będą dążyć do zbieżności lub oscylacji wokół czegoś, co działa dla nich (+/-). Kod Complete może wpływać na niektóre wartości początkowe lub może pociągać firmy w taki czy inny sposób. Firma, która poświęca zbyt wiele wysiłku na usuwanie wad, których nikt by nie zauważył, prawdopodobnie straci biznes dla konkurenta, który ma bardziej zoptymalizowane podejście. Z drugiej strony firma wypuszczająca produkty buggy również przestanie działać.

Kilka istotnych artykułów z szybkiego wyszukiwania (przeczytaj pełne artykuły, zrób więcej badań i sformułuj własną opinię):

Systematyczny przegląd literatury dotyczący badania kosztów jakości oprogramowania (2011)

„Chociaż społeczność opracowała w ten sposób solidne zrozumienie struktury dziedziny badawczej, często brakuje empirycznej weryfikacji. Tylko około jedna trzecia analizowanych artykułów przedstawia studium przypadku lub bardziej obszerne wyniki empiryczne. Wydaje się to niewystarczające do badania kosztów jakości oprogramowania , który silnie opiera się na danych ilościowych w celu wygenerowania nowych ustaleń. Istnieje zatem potrzeba nowatorskich podejść do gromadzenia danych o wysokiej jakości, a także ściślejszej współpracy między przemysłem a badaniami w celu udostępnienia takich danych ”.

Ocena kosztu jakości oprogramowania (1998)

„Wreszcie zauważyliśmy, że ważne jest monitorowanie kosztów zgodności oprogramowania i kosztów niezgodności, aby można było dostosować zasady zgodności w celu zmniejszenia całkowitych kosztów jakości oprogramowania”.

Zachowanie kosztowe wad oprogramowania (2004)

Streszczenie ... „Obecne badania próbują zaktualizować naszą wiedzę o sposobie, w jaki defekty i koszt ich naprawy (lub alternatywnie pozostawienie ich nieskorygowanych) wpływają na końcowy koszt oprogramowania„ ... ”nieskorygowane defekty stają się wykładniczo bardziej kosztowne z każdą fazą, w której są nierozwiązane ”

Pokrycie testowe i wady po weryfikacji: wielokrotne studium przypadku (2009)

„Stwierdzamy również, że wysiłek testowy rośnie wykładniczo wraz z pokryciem testowym, ale zmniejszenie problemów w terenie wzrasta liniowo wraz z pokryciem testowym. Sugeruje to, że w przypadku większości projektów optymalne poziomy pokrycia mogą być znacznie niższe niż 100%”.

Wypełnij lukę między procesem testowania oprogramowania a wartością biznesową: studium przypadku (2009)

Nie mogę odpowiedzieć na pierwszą część pytania, ponieważ po prostu tego nie sprawdziłem. Ale mogę sformułować odpowiedź na twoje drugie pytanie i być może wskazać możliwą odpowiedź na pierwsze.

Nie trzeba dodawać, że niektóre najważniejsze czynniki związane z kosztem naprawy błędu, wykluczające wewnętrznie trudne w użyciu narzędzia programistyczne, to wewnętrzna złożoność produktu i to, jak dobrze użytkownik może go zrozumieć.

Koncentrując się na sekundę na kodzie, przy założeniu, że kod jest zwykle pisany i utrzymywany przez programistów zdolnych do radzenia sobie z wewnętrzną złożonością ich kodu (co może nie być do końca prawdą i może zasługiwać na własną debatę), odważyłbym się zasugerować, że kluczowe znaczenie w konserwacji, a tym samym w naprawianiu błędów, to zdolność opiekunów do zrozumienia wspomnianego kodu.

Zdolność rozumienia kodu jest znacznie zwiększona dzięki zastosowaniu sprawdzonych narzędzi inżynierii oprogramowania, które są niestety najczęściej niedostatecznie lub niewłaściwie używane. Zastosowanie odpowiedniego poziomu abstrakcji, modułowości, zwiększenie spójności modułu i zmniejszenie sprzężenia modułów są kluczowymi narzędziami w radzeniu sobie ze złożonością, która wymaga właściwego użycia. Kodowanie do interfejsów lub, w OOP, unikanie nadmiernego wykorzystania dziedziczenia nad kompozycją, pakowanie według cech, to niektóre z technik, którym często przypisuje się niewystarczającą uwagę w kodowaniu.

Uważam, że realia konkurencji w branży negatywnie wpływają na stosowanie metod zwiększania jakości w tworzeniu oprogramowania, utrzymując niską jakość oprogramowania jako miernik ciągłego sukcesu.

W związku z tym uważam, że w branży oprogramowanie jest bardziej narażone na koszty naprawiania błędów, im większy rośnie. W takich produktach błędy z czasem stają się trudniejsze do usunięcia, ponieważ system staje się trudniejszy do zrozumienia wraz z rozwojem. Obawy wprowadzone przez każdą funkcję są nadmiernie połączone z innymi problemami, co utrudnia zrozumienie. Lub nie zastosowano odpowiedniego poziomu abstrakcji, co utrudnia opiekunowi sformułowanie odpowiedniego modelu systemu i uzasadnienie tego. Brak dokumentacji z pewnością nie pomaga.

Istnieją wyjątki. Jestem pewien, że Google nie działa w swoim tempie bez solidnych praktyk popartych przez gwiezdnych programistów. Inni prawdopodobnie znajdują się w tej samej sytuacji. Ale dla większości oprogramowania, nie będę zaskoczony, jeśli dane nie faktycznie potwierdzają twierdzenie w Kodeksie pełna .

Kolejna odpowiedź! Tym razem, aby odpowiedzieć na tytułowe pytanie „Czy morhtodoligia oprogramowania opiera się na błędnych danych”.

Prawdziwa odpowiedź brzmi: „nie ma danych”. Ponieważ nie ma dużego, wiarygodnego zbioru danych o projektach oprogramowania, wady, sukces na rynku itp.

Wszystkie próby gromadzenia takich danych były niedofinansowane, statystycznie błędne lub ,, tak specyficzne dla konkretnego projektu, że nie można wyciągnąć ogólnych wniosków.

Co więcej, nie sądzę, żeby kiedykolwiek tak się stało, proces tworzenia oprogramowania jest zbyt subiektywny i śliski dla ścisłego pomiaru. Organizacje, które najlepiej potrafią gromadzić takie dane (duże domy oprogramowania i integratorzy systemów) wiedzą w swoich sercach, że wszelkie liczby zebrane z ich działalności byłyby głęboko zawstydzające.

Jedynymi organizacjami, które publikują liczby na temat kosztów i powodzenia projektów oprogramowania,
są departamenty rządowe i tylko dlatego, że muszą, i tak, liczby te są głęboko zawstydzające, bez względu na to, jak bardzo masują liczby.

Podsumowując, wszystkie badania oprogramowania są z konieczności czysto subiektywne, ponieważ nie ma rzeczywistych danych, na których można by oprzeć obiektywne wnioski.