Fakten und Irrtümer der Softwaretechnik

Robert L. Glass

Genres: Programmierung

Jahr der Veröffentlichung: 2008

Jahr der Lektüre: 2020

Meine Bewertung: Höchste

Anzahl der Lesevorgänge: 1

Gesamtseitenzahl: 233

Zusammenfassung (Seiten): 0

Originalsprache der Veröffentlichung: Englisch

Übersetzungen in andere Sprachen: Russisch, Chinesisch

Allgemeine Informationen

Das Buch aus dem Jahr 2008 besteht aus 55 Fakten und 10 Missverständnissen über Entwickler und Programmierung im Allgemeinen. Alle Materialien sind in bestimmte Gruppen unterteilt, z.B. Management, Entwicklung und andere.

Es ist wichtig zu erwähnen, dass fast alle Themen und Fragen, die vom Autor behandelt werden, sehr umstritten sind (heiß diskutiert), und die Meinungen der Leser erheblich auseinandergehen können. Um Zeit und Platz zu sparen, werde ich meine eigene Meinung zu jedem Punkt nicht ausführlich darlegen. Ich werde hier nur schnell alle Fakten und Missverständnisse aufzählen und am Ende eine allgemeine Bewertung des Buches abgeben. Jeder Fakt oder jedes Missverständnis ist ungefähr so ausführlich wie ein mittellanger Artikel, daher können Sie das Buch auch nur teilweise lesen und sich auf bestimmte Themen konzentrieren. Bevor ich alle Fakten und Missverständnisse aufzähle, möchte ich auch darauf hinweisen, dass der Autor eine klare Struktur bei der Präsentation des Materials einhält:

• Er diskutiert zunächst den Fakt oder das Missverständnis.
• Dann beschreibt er die Kontroversen und Debatten zu diesem Thema.
• Am Ende gibt er Quellen an, die sich auf das Thema beziehen.

Fakten der Programmierung

Menschlicher Faktor

1. Der wichtigste Faktor in der Softwareentwicklung sind nicht die Methoden und Werkzeuge, die von Programmierern verwendet werden, sondern die Programmierer selbst.
2. Eine Untersuchung über persönliche Unterschiede zeigt, dass die besten Programmierer bis zu 28-mal besser sind als die schlechtesten. Wenn man bedenkt, dass ihre Bezahlung nie proportional ist, ist der beste Programmierer das wertvollste Gut in der Softwarebranche.
3. Wenn ein Projekt nicht im Zeitrahmen liegt, verzögert das Hinzufügen von Arbeitskräften das Projekt noch mehr.
4. Arbeitsbedingungen haben einen starken Einfluss auf die Produktivität und die Qualität des Ergebnisses.
5. Die Werbung rund um Werkzeuge und Methoden ist das Plage der Softwarebranche. Viele Verbesserungen der Werkzeuge und Methoden führen zu einer Produktivitäts- und Qualitätssteigerung von etwa 5-35%. Aber viele dieser Verbesserungen wurden als bahnbrechend angekündigt.
6. Das Erlernen einer neuen Methode oder eines neuen Werkzeugs reduziert zunächst die Produktivität der Programmierer und die Qualität des Produkts. Der Nutzen des Lernens wird erst nach dem Durchlaufen der Lernkurve sichtbar. Daher ist es nur sinnvoll, neue Methoden und Werkzeuge einzuführen, wenn man a) ihren tatsächlichen Wert sieht und b) Geduld hat, auf den Gewinn zu warten.
7. Entwickler sprechen viel über Werkzeuge. Sie probieren viele aus, kaufen sie in ausreichender Menge, aber sie arbeiten kaum damit.
8. Eine der häufigsten Ursachen für das Fehlen von Projektkontrolle ist eine schlechte Schätzung. (Die zweite Ursache wird in Fakt 23 behandelt.)
9. Die meisten Schätzungen in Softwareprojekten erfolgen zu Beginn des Lebenszyklus. Das stört uns nicht, bis wir realisieren, dass die Schätzungen gemacht wurden, bevor die Anforderungen definiert wurden, und daher, bevor die Aufgabe untersucht wurde. Folglich werden Schätzungen normalerweise nicht zur richtigen Zeit gemacht.
10. Die meisten Schätzungen in Softwareprojekten werden entweder von Top-Managern oder von Marketingmitarbeitern gemacht, und nicht von denen, die die Software entwickeln werden, oder deren Führungskräften. Daher wird die Schätzung nicht von den richtigen Personen gemacht.
11. Schätzungen in Softwareprojekten werden selten später angepasst. Mit anderen Worten, Schätzungen, die nicht von den richtigen Personen und nicht zur richtigen Zeit gemacht wurden, werden in der Regel nicht korrigiert.
12. Da Schätzungen so ungenau sind, gibt es nicht viele Gründe, sich Sorgen zu machen, dass Softwareprojekte nicht innerhalb der geschätzten Zeit abgeschlossen werden. Trotzdem machen sich alle Sorgen darüber.
13. Es gibt keinen Kontakt zwischen Managern und Programmierern. In einer Untersuchung eines Projekts, das die in der Schätzung festgelegten Parameter nicht erfüllt hat und von der Führung als Misserfolg betrachtet wurde, berichteten die technischen Mitarbeiter, dass es das erfolgreichste Projekt war, an dem sie jemals gearbeitet hatten.
14. Die Machbarkeitsanalyse eines Projekts ergibt fast immer eine Antwort „ja“.
15. Die Wiederverwendung „im kleinen Maßstab“ (in Unterprogrammbibliotheken) existiert seit fast 50 Jahren und ist gut etabliert.
16. Die Aufgabe der Wiederverwendung „im großen Maßstab“ (in Komponenten) bleibt größtenteils ungelöst, obwohl alle sich einig sind, dass dies sehr wichtig ist.
17. Der Erfolg der Wiederverwendung im großen Maßstab ist am größten in Familien verwandter Systeme und hängt daher stark vom Fachgebiet ab. Das schränkt die potenzielle Anwendbarkeit der Wiederverwendung im großen Maßstab ein.
18. In der Praxis der Wiederverwendung gibt es zwei „Dreier-Regeln“: a) Häufig verwendete Komponenten sind dreimal so aufwändig wie einmal verwendete Komponenten; und b) Eine häufig verwendete Komponente muss in drei verschiedenen Anwendungen getestet werden, bevor sie als ausreichend allgemein angesehen werden kann, um in eine Komponentenbibliothek aufgenommen zu werden.
19. Die Modifikation wiederverwendeten Codes ist äußerst fehleranfällig. Wenn mehr als 20-25% des Codes einer Komponente geändert werden müssen, ist es besser, ihn von Grund auf neu zu schreiben.
20. Die Wiederverwendung von Designmustern ist eine Lösung für die Probleme, die mit der Wiederverwendung von Code verbunden sind.
21. Eine Erhöhung der Komplexität einer Aufgabe um 25% führt zu einer Verdopplung der Komplexität der Softwarelösung. Das ist keine Bedingung, die man ändern kann (obwohl es immer wünschenswert ist, die Komplexität zu minimieren), sondern eine Tatsache.
22. 80% der Arbeit in der Softwareentwicklung bestehen aus intellektueller Arbeit. Ein beträchtlicher Teil davon kann als kreativ bezeichnet werden. Und nur ein kleiner Teil davon ist technisch.

Anforderungen

23. Eine der zwei häufigsten Ursachen für das Fehlen von Projektkontrolle sind sich ändernde Anforderungen. (Die andere Ursache wird in Fakt 8 behandelt.)
24. Fehlerkorrekturen in Anforderungen sind am teuersten, wenn sie in der Betriebsphase entdeckt werden, und am günstigsten, wenn sie in den frühen Entwicklungsphasen entdeckt werden.
25. Nicht vorhandene Anforderungen sind der schwerste Fehler, den man korrigieren kann.

Design

26. Im Verlauf der Entwicklung von den anfänglichen Anforderungen zur Architektur überschlagen uns eine Vielzahl von „abgeleiteten Anforderungen“ (Anforderungen an spezifische Designlösungen), die durch die Komplexität des Prozesses entstehen. Diese Liste der abgeleiteten Anforderungen ist oft 50-mal länger als die ursprüngliche.
27. Die beste Designlösung für eine Programmieraufgabe ist selten die einzige.
28. Design ist ein komplexer iterativer Prozess. Die anfängliche Designlösung wird wahrscheinlich falsch und sicherlich nicht optimal sein.

Codierung

29. Programmierer wechseln vom Design zum Codieren, wenn die Aufgabe auf das Niveau von „Primitiven“ heruntergebrochen wurde, mit denen der Designer vertraut ist. Wenn der Programmierer und der Designer unterschiedliche Personen sind, werden die Primitiven des Designers wahrscheinlich nicht mit denen des Programmierers übereinstimmen, was zu Problemen führen wird.
30. COBOL ist eine sehr schlechte Sprache, aber alle anderen (für die Verarbeitung von Geschäftsdaten) sind noch schlechter.
31. Die Fehlerbehebungsphase ist die arbeitsintensivste im Lebenszyklus.

Testen

32. Es stellt sich heraus, dass in Software, von der ein typischer Programmierer glaubt, dass sie gründlich getestet wurde, oft nur 55–60% der logischen Pfade überprüft wurden. Der Einsatz automatisierter Werkzeuge wie Coverage-Analysern kann diesen Anteil auf etwa 85–90% erhöhen. Es ist praktisch unmöglich, 100% der logischen Pfade in Software zu testen.
33. Selbst wenn 100% Testabdeckung möglich wäre, wäre sie kein geeigneter Maßstab für die Testangemessenheit. Etwa 35% der Softwarefehler werden durch übersehene logische Pfade verursacht, und weitere 40% hängen mit der Ausführung einzigartiger Kombinationen von logischen Pfaden zusammen. Diese können bei 100% Testabdeckung nicht entdeckt werden.
34. Ohne Werkzeuge ist es fast unmöglich, Fehlerbeseitigung qualitativ durchzuführen. Häufig werden Debugger verwendet, im Gegensatz zu anderen Werkzeugen wie Test-Coverage-Analyzern.
35. Tests werden selten automatisiert. Das bedeutet, dass bestimmte Testprozesse automatisiert werden können und sollten. Aber einen erheblichen Teil der Testarbeit kann man nicht automatisieren.
36. Ein wichtiges zusätzliches Werkzeug für das Testen ist der vom Programmierer geschriebene eingebettete Debugging-Code, der vorzugsweise in den Objektcode aufgenommen wird, abhängig von den Kompilierungsdirektiven.
37. Gründliche Inspektionen ermöglichen es, bis zu 90% der Fehler aus dem Softwareprodukt zu entfernen, bevor der erste Referenztest durchgeführt wird.
38. Gründliche Inspektionen bieten viele Vorteile, aber sie können das Testen nicht ersetzen.
39. Es ist allgemein anerkannt, dass nachträgliche Reviews (auch retrospektiv genannt) sowohl aus Sicht des Verbrauchers (Benutzers der Software) als auch zur Verbesserung des Prozesses wichtig sind. In den meisten Organisationen werden jedoch keine retrospektiven Reviews durchgeführt.
40. In Inspektionen spielen neben technischen Faktoren auch soziale eine Rolle. Zu viel Aufmerksamkeit auf das eine zu richten, auf Kosten des anderen, ist der direkte Weg zum Desaster.
41. Die Wartungskosten betragen normalerweise 40 bis 80% (im Durchschnitt 60%) der Kosten der Software. Daher ist diese Phase ihres Lebenszyklus möglicherweise die wichtigste.
42. Etwa 60% der Wartungskosten entfallen auf die Verbesserung des Codes, und etwa 17% auf die Fehlerbehebung. Somit besteht Wartung hauptsächlich darin, neue Funktionen hinzuzufügen und nicht, Fehler zu beheben.
43. Wartung ist eine Lösung, kein Problem.
44. Wenn man die Aufgaben der Softwareentwicklung und -wartung vergleicht, sind sie größtenteils gleich – mit Ausnahme der zusätzlichen Aufgabe der Wartung, die als "Studium des gewarteten Produkts" formuliert wird. Diese nimmt etwa 30% der gesamten Wartungszeit in Anspruch, und dieser Aspekt dominiert in der Wartung. Daher kann man sagen, dass Wartung arbeitsintensiver ist als Entwicklung.
45. Die Verbesserung der Qualität der Softwareentwicklung führt dazu, dass die Wartung mehr wird, nicht weniger.

Qualität

46. Qualität ist eine Gesamtheit von Eigenschaften.
47. Qualität wird nicht durch die Zufriedenheit des Benutzers, die Übereinstimmung mit den Anforderungen des Kunden, die Akzeptanz des Preises und die Einhaltung der Produktlieferfristen oder Zuverlässigkeit definiert.
48. Es gibt Fehler, zu denen die meisten Programmierer neigen.
49. Fehler neigen dazu, Cluster zu bilden.
50. Es gibt noch keinen einzigen besten Ansatz zur Fehlerbeseitigung.
51. Fehler sind unvermeidlich. Das Ziel ist es, kritische Fehler zu vermeiden oder sie auf ein Minimum zu reduzieren.

Effizienz

52. Effizienz hängt mehr von der qualitativ hochwertigen Gestaltung der Anwendung ab als vom qualitativen Programmieren.
53. Die Effizienz von Code in einer Hochsprache, der mit den entsprechenden Optimierungsparametern kompiliert wurde, kann bis zu 90% der Effizienz von funktional vergleichbarem Assemblersprachen-Code erreichen. In einigen modernen komplexen Architekturen kann sie sogar höher sein.
54. Es gibt Kompromisse zwischen Optimierung nach Größe und Optimierung nach Geschwindigkeit. Häufig führt die Verbesserung des ersten Werts zur Verschlechterung des zweiten.

Über wissenschaftliche Forschungen

55. Viele Wissenschaftler, die in der Programmierindustrie tätig sind, neigen eher dazu, ihre Theorien zu verteidigen, als Forschung zu betreiben. Das Ergebnis: a) der Wert einiger propagierter Theorien ist viel geringer, als die Propagandisten selbst denken; b) es gibt wenig Forschung, die helfen würde, den wahren Wert dieser Theorien zu bestimmen.

Programmiermythen

1. Man kann nicht steuern, was man nicht messen kann.
2. Management kann ein Softwareprodukt qualitativ machen.
3. Programmierung kann und sollte unpersönlich sein.
4. Werkzeuge und Technologien sind universell.
5. Programmierung benötigt mehr Methodologien.
6. Um die Kosten und den Zeitrahmen zu schätzen, zählen Sie zuerst die Codezeilen.
7. Die Verwendung von zufälligen Eingabedaten ist ein guter Weg, das Testen zu optimieren.
8. „Alle Fehler werden sichtbar, wenn genug Augen auf sie gerichtet sind.“
9. Wenn man weiß, was die Wartung im vorherigen Fall gekostet hat, kann man vorhersagen, was sie in der Zukunft kosten wird, und eine Entscheidung über die Zweckmäßigkeit eines Produktwechsels treffen.
10. Man kann Menschen Programmieren beibringen, indem man ihnen zeigt, wie man Programme schreibt.

Fazit

Obwohl das Buch bereits 2008 geschrieben wurde, empfehle ich es dennoch allen, die Programmierung lernen. Ein Nachteil, der sofort ins Auge fällt, ist die Schwierigkeit, die Prozentsätze und Zahlen zu bestätigen oder zu widerlegen, die der Autor in einzelnen Fakten angibt. Es gibt auch einige Fakten, die heute bereits nicht mehr aktuell sind. Der Großteil des Materials bleibt jedoch weiterhin relevant, und es ist für Entwickler sowie Manager hilfreich, sich damit vertraut zu machen.