Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03412.jsonl.gz/895

Windows 8x hat 60 Millionen Zeilen Quellcode.
Eine typische Linux Distribution 204 Millionen Zeilen.
MVS/ESA, eines der stabilsten Betriebssysteme, das je gebaut wurde, hatte 1 Million Zeilen.
OS/400 ein weiteres nachweislich unter den stabilsten: 2 Millionen.
Wartungszyklen ('Patchdays'):
Win: Monatlich
Linux: Täglich
MVS und OS/400: Quartal.
Fehlerraten:
Der Industriedurchschnitt an Fehlern (‘Bugs) ist 15 – 50 pro 1000 Zeilen, abhängig von den Coding-Techniken.
MS: Inhouse Tests: 10 – 20 Defekte pro 1000 Zeilen. Ausgelieferte Versionen: 0,5 pro 1000 Zeilen.
Cleanroom Development nach Harlan Mills: 3 Defekte pro 1000 Zeilen inhouse und 0,1 Release-Version.
Entgegen der Intuition steigt die Fehlerrate nicht überproportional zur Anzahl Quell Code Zeilen. Es ist statistisch gesehen eine lineare Funktion. Wird der Mittelwert der Fehlerquote des Industriedurchschnitts genommen, also 32,5, so bestehen 32 Defekte pro 1000 Zeilen in der Phase inhouse tests, 64 pro 2000, usw. Diese Rate ist konstant und unabhängig von der Sprache des Quell Codes. Die Fehler Quote des ausgelieferten Produktes ist aber direkt abhängig von der Methode des Projekt Managements, bzw Changemanagements, die Test Methodik, und da der Unterschied zwischen formalen Testfällen zur Abnahme versus statistische Verfahren der Fehler Findung. (Formale Testfälle finden wegen des inhärenten Selektionsbias viele Defekte nicht). Auch mit den statistischen Verfahren nach Cobb und Mills gibt es sehr wenige Projekte, die je eine Rate von 0 Defekten des ausgelieferten Produktes erreichten. Diese haben alle weniger als 500‘000 Zeilen Quell Code (als Beispiel die Software des Space Shuttle).
Quelle: Steve McConnell, Code Complete und Cobb and Mills.
Soweit das wissenschaftliche. Es gibt also theoretisch schon keine fehlerfreie Software, ausser bei eingebetteter Industriesoftware mit überschaubarer Code-Menge und mit sehr rigorosen und sehr teuren Methoden der Qualitätssicherung. Die Wartungszyklen oben sind aber ein Hinweis darauf, dass der Grad der Offenheit eines Systems kombiniert mit einem Fehlen rigoroser integrierter Tests die Wahrscheinlichkeit, Defekte nicht zu finden, erhöht.
Die Consumer- bzw Communityversionen von Linux sind da statistisch gesehen eher am schlechten Ende. Die teuren, bezahlten Versionen mit methodischem Releasemanagement am guten Ende. Letzteres betrifft auch die proprietären Systeme). MS steht etwas dazwischen, da MS im Releasemanagement einen Kompromiss zwischen schneller Response und geprüfter Stabilität fährt, aber durch die Planbarkeit punktet.