111 Thesen zur erfolgreichen Softwareentwicklung (eBook)

Danksagung 6
Vorwort 7
Inhaltsverzeichnis 17
1 Thesen 23
1.1 Einführung in das Konzept 23
1.2 Mehr Chancen durch bessere Strategien 27
1.2.1 Optimale Arbeitsteilung 29
1.2.2 Arbeitsplätze im Wandel 31
1.2.3 Synergie muss organisiert werden 32
1.2.4 Offen sein für Problemlösungen 35
1.2.5 Helfen, nicht beschränken 36
1.2.6 Probleme richtig verstehen 37
1.2.7 Simplifizieren durch Organisieren 38
1.2.8 Mehr erreichen durch strategische Entscheidungen 43
1.2.9 Interdisziplinäre Kooperation – eine effektive Strategie 45
1.2.10 Mehr Zuverlässigkeit und Effizienz durch Automation 49
1.2.11 Ohne richtige Dimensionierung geht nichts 51
1.2.12 Komplexität – weniger ist mehr 52
1.2.13 Mensch-Maschine-Schnittstelle 55
1.2.14 Ohne Zusatzaufwand unendlich viele Fälle abdecken 58
1.2.15 Qualitätssicherung 59
1.2.16 Schnittstellenanpassung 62
1.2.17 Dokumentation 63
1.3 111 Thesen zur effizienten Softwareentwicklung 64
1.3.1 Stand der Technik 64
1.3.2 Wettbewerb 64
1.3.3 Softwareentwicklung 64
1.3.4 Organisation 65
1.3.5 Schnittstellen 66
1.3.6 Information 67
1.3.7 Automation 67
1.3.8 Strategie 68
1.3.9 Kostenschätzung 69
1.3.10 Projektmanagement 69
1.3.11 Management 70
1.3.12 Qualitätssicherung 70
2 Strategische Ausrichtung 73
2.1 Wann ist man effizient und erfolgreich? 74
2.2 Mehr Effizienz durch Automatische Softwareproduktion 75
2.3 Software korrekt produzieren durch Automation 77
2.3.1 Anforderungen korrekt umsetzen 78
2.3.2 Verifikation und Validierung – was Softwareentwickler und Bäcker brauchen 79
2.3.3 Synergien erzeugen 80
2.3.4 Vom Compiler zum Systemcompiler 82
2.3.5 Selbstkontrolle 83
2.3.6 Ist Selbstkontrolle sinnvoll? 84
2.4 Entwickeln impliziert Projektmanagement 85
2.5 Organisation der Entwicklung 87
2.6 Wie groß ist das Einsparungspotenzial? 89
2.7 Welcher Weg ist der beste? 90
2.8 Automatisierung effizient einsetzen 96
2.9 Weniger ist mehr - durch Einschränkungen mehr erreichen 98
2.10 Effizient Entwicklungsrisiken meistern 101
2.11 Komplexität meistern 104
2.12 Effiziente Wartung 108
3 Risiken und Chancen in der Softwareentwicklung 111
3.1 Rollenverteilung 111
3.2 Professionelle Softwareentwicklung – Herausforderung 113
3.2.1 Risiken durch Informationsmangel 114
3.2.2 Risiken durch Managementfehler 115
3.2.3 Der Kampf gegen das Chaos 116
3.3 Fehlentscheidungen 118
3.3.1 Viel Code, wenig Qualität 118
3.3.2 Wie zuverlässig sind Ergebnisse? 119
3.3.3 Der Anwender ist nicht König 124
3.4 Risiken 130
3.4.1 Interne Risiken 130
3.4.2 Externe Risiken 138
3.5 Softwareentwicklungswerkzeuge 148
3.5.1 Anwendungsprofil und Parametrisierbarkeit 148
3.6 Geringeres Risiko durch schnellere Umsetzung? 151
3.7 Durch Tests Fehler erkennen 153
3.8 Qualität 159
3.9 Organisation der Automation 162
3.10 Komplexität 165
3.10.1 Große Mengen, große Komplexität 166
3.10.2 Unübliche Regeln, hohe Komplexität 166
3.10.3 Gegenmaßnahmen 168
3.11 Das Potenzial der Automation 170
4 Entwicklungsgrundlagen 173
4.1 Manuelle Softwareentwicklung 173
4.2 Entwicklungsansätze 174
4.3 Anforderungen an automatische Prozesse 180
4.3.1 Grenzen der Teilautomation 180
4.3.2 Einfluss auf Korrektheit, Konsistenz und Vollständigkeit 180
4.4 Qualitätssicherung 183
4.4.1 Qualitätsmerkmale 183
4.4.2 Qualitätssicherungsstandards 185
4.4.3 Zertifizierung 188
4.4.4 Klassifizierung von Werkzeugen 190
4.4.5 Verifikation und Validierung 190
4.5 Zuverlässigkeit 194
4.5.1 Pragmatische Ansätze zur Bestimmung der Zuverläsigkeit 194
4.5.2 Aktive Qualitätssicherung: Maßnahmen gegen Fehler 196
4.6 Betriebssysteme – Effizienz und Risiken 218
4.6.1 Softwarequalität hängt vom Betriebssystem ab 219
4.6.2 Klassifikationskriterien 220
4.7 Hilfen für die Softwareentwicklung 227
4.7.1 Methoden 228
4.7.2 Generatoren 231
4.7.3 Sprachen 234
4.7.4 Unterstützung der Fehlerprävention und Fehlererkennung durch Sprachen 240
5 Managementaspekte 248
5.1 Das Rationalisierungspotenzial 248
5.2 Was lässt sich ändern? 251
5.3 Argumente und Gegenargumente 253
5.3.1 Der indifferente Ansatz 253
5.3.2 Der "Mengen"-Ansatz 254
5.4 Wo lohnt es sich? 256
5.4.1 Kosten vs. Entwicklungsphasen 257
5.4.2 Kosten der Fehlerbeseitigung 261
5.4.3 Sparen bei Wartung und Pflege / Legacy Software 265
5.4.4 Strategie zur Kostensenkung 266
5.5 Organisatorische Maßnahmen 269
5.5.1 Das Baukastensystem 270
5.5.2 Spezifikation 273
5.5.3 Test, Verifikation und Validierung 277
5.5.4 Die Abnahme 278
5.5.5 Wartung und Legacy Systeme 280
5.5.6 Vertragliche Aspekte und Projektorganisation 281
5.5.7 Hindernisse wegräumen 284
5.5.8 Qualitätssicherung durch Standards 287
5.6 Wettbewerbsvorteile 287
5.7 Managementaufgaben 288
5.7.1 Kostenanalyse 289
5.7.2 Erfolgsanalyse 291
5.7.3 Risikoanalyse und Risikominimierung 292
5.7.4 Fehleranalysen 294
5.7.5 Empfehlungen zur Optimierung 295
5.8 Checkliste 297
6 Automatische Softwareproduktionsprozesse 311
6.1 Ziele des vollautomatischen Produktionsprozesses 311
6.2 Voraussetzungen für die Prozessdefinition 313
6.3 Entwicklerprofile 315
6.4 Die Prozessdefinition 316
6.5 Produktionsprozesse – im wesentlichen nichts Neues 318
6.5.1 Anwendungsorientierte Produktionsprozesse 318
6.5.2 Spezialisierung vs. Vereinheitlichung 321
6.5.3 Der konfigurierbare Produktionsprozess 323
6.5.4 Vollautomatische Produktionsprozesse 325
6.5.5 Prozessparameter 326
6.5.6 Typen von Produktionsprozessen 332
6.5.7 Identifizierung von Abhängigkeiten 341
6.5.8 Konstruktionsregeln 343
6.5.9 Metamodelle 353
6.5.10 Eigenschaften vollautomatischer Produktionsprozesse 353
6.5.11 Verifikation von Prozessen und Qualitätssicherung 359
6.5.12 Validierung und automatische Testfallerzeugung 368
6.5.13 Kontinuierliche Wartung 369
6.5.14 Systemcompiler 370
6.5.15 Teilprodukte und vertragliche Aspekte 371
6.6 Der automatische Entwicklungszyklus 376
6.7 Die Vorteile für ein einzelnes Projekt 380
6.8 Merkmale eines vollautomatischen Produktionsprozesses 382
6.9 Weitere Ansätze auf dem Gebiet der Automation 387
7 Vollautomation als Realität 389
7.1 Über die Einführung und Optimierung neuer Methoden 389
7.2 Durchgängig von der Spezifikation bis zum Betrieb 393
7.2.1 Von der Spezifikation zum Produkt 394
7.2.2 Die Realisierung 402
7.2.3 Ergebnisse 404
7.3 Reengineering und n-Version- Development 408
7.3.1 Vom Reengineering zu n-Version-Development 411
7.4 Redundanzreduktion bei Parsern 415
7.4.1 Formale Beschreibung von Sprachen 416
7.4.2 Transformation von Grammatiken 417
7.4.3 Die Entstehung von Redundanzen 419
7.4.4 Die Risiken von Redundanzen und ihre Eliminierung 420
7.5 Algorithmen 421
7.5.1 Datenkonvertierung 422
7.5.2 Ausnutzung theoretischer Möglichkeiten in der Praxis 427
7.6 Verteilte Echtzeitsysteme 429
7.6.1 Master-Slave Struktur 432
7.6.2 Echtzeitinfrastruktur 436
7.6.3 Spezifikation und Erzeugung der MSL-Datenbank 440
7.7 Ein synchrones verteiltes System 443
7.8 Client-Server Anwendungen, Datenbanken und GUIs 445
7.8.1 SQL-Datenbanken aus einem Guss 450
7.8.2 Grafische Oberflächen aus C-Typdefinitionen 457
7.9 Schnittstellenanpassung 459
7.10 Automatische Testumgebungen 460
7.10.1 Funktionstests 460
7.10.2 Test des Verhaltens 462
7.11 Effizienzanalyse 463
7.12 Rückblick und Ausblick 469
8 Gesellschaftliche Aspekte 471
8.1 Sozialpolitische Relevanz 472
8.1.1 Innovation und die Folgen 473
8.1.2 Sozialverträglichkeit 474
8.1.3 Konkurrenzfähigkeit 475
8.1.4 Der Softwareentwickler, zuerst geschützt, dann gehetzt 476
8.2 Das Arbeitsumfeld 478
8.2.1 Rückblick 478
8.2.2 Ausblick 479
8.2.3 Kooperation ist notwendig 480
8.2.4 Der Anpassungsprozess 480
8.3 Wirtschaftliche Relevanz 484
8.3.1 Mehr Synergie durch neue Produktionsmethoden 484
8.3.2 Egalisieren vs. Spezialisieren 486
8.3.3 Automatische Produktion vs. Fremdentwicklung 488
8.4 Ausbildungspolitische Relevanz 489
8.4.1 Der Kunde ist König 489
8.4.2 Automation impliziert Qualifikation 491
8.5 Zusammenfassung 493
9 Schlussbemerkungen und Ausblick 495
Abkürzungen und Synonyme 498
Begriffe 502
Literatur 517
Sachverzeichnis 528

3.2 Professionelle Softwareentwicklung – die Herausforderung (S.91)

Software entwickeln kann jeder, so könnte man denken. Man kauft sich einen Computer, besorgt sich (eventuell sogar kostenlos) einen Compiler, und schon kann man ein Programm entwickeln. Mit den heute zur Verfügung stehenden Ressourcen für CPU und Speicher werden weder Programmgröße noch Komplexität Grenzen gesetzt.

Bei der Fertigung von Hardware dagegen werden Hilfsmittel benötigt, die nicht leicht zu beschaffen sind und auch spezielle Vorrichtungen für die Benutzung erfordern. Zum Bau von Möbeln werden bereits Werkzeuge benötigt, die sachgemäße Bedienung und Vorkenntnisse erfordern.

Zwar kann die sich jeder – je nach Geschick – aneignen, aber man erkennt schnell, dass ohne Übung kein professionelles Ergebnis entsteht. Bei Hardware erkennt man schnell Mängel, funktionale – wenn ein Stuhl wackelt oder kippt, und nicht-funktionale – wenn er zu schwach ist oder die Lackierung fehlerhaft ist.

Dagegen verhält sich Software wie ein Gas

- denn sie nimmt jeden verfügbaren Raum ein, Zeit und Geld, Speicher und Rechnerleistung

- denn sie ist unsichtbar, wir können ihre Eigenschaften nicht sehen wie eine Chemikalie

- denn bei unsachgemäßer Handhabung kommt es zur Katastrophe, die Eigenschaften der verwendeten Substanz und ihre Wirkung sind unbekannt

Mit diesen für die Entwickler so problematischen Eigenschaften haben wir bei der Entwicklung von Software zu kämpfen. Während wir für Hardware "Sensoren" wie Augen, Nase, Ohren und Tastsinn haben, fehlen uns die geeigneten Sensoren für Software. Die Eigenschaften von Software, die positiven und die negativen – wie Fehler, können wir erst dann erkennen, wenn sie für uns sichtbar werden durch Hilfsmittel wie Drucker, Monitor, Datendisplays oder akustische Signale.

3.2.1 Risiken durch Informationsmangel

Wird nicht genügend für die "Visualisierung" der Eigenschafen in einer für Menschen leicht verständlichen Präsentation gesorgt (im übertragenen Sinn zählen wir zur Visualisierung nicht nur die Wahrnehmung durch Augen, sondern auch durch Ohren sowie den Tast- und Riechsinn), dann werden Abweichungen von den Vorgaben – also Fehler – nicht frühzeitig genug wahrgenommen.

Visualisierung der Software ist mit Aufwand verbunden. Zur Minimierung der Kosten wird man sich daher erst einmal auf das unbedingt Notwendige beschränken, wodurch ein nicht unerhebliches Risiko entstehen kann, da man dann möglicherweise nicht alle Eigenschaften des entstehenden oder fertigen Produkts erfährt. Denn mangelhafte Visualisierung impliziert fehlende Information, fehlende Information führt zur falschen Einschätzung der Situation, und bei der Softwareentwicklung in der Regel zur Unterschätzung oder zum Ignorieren eines Problems.

Ein typisches Beispiel hierfür sind Schnittstellen zwischen Softwarekomponenten wie Funktionen oder Teilprogrammen. Hier treten Probleme auf, wenn wegen mangelnder Visualisierung Inkompatibilitäten übersehen werden. Dann werden Probleme zu spät erkannt, was zu erheblichen Zusatzkosten und meistens auch zu Terminverzug führt.

Die bei der Softwareentwicklung auftretenden Probleme sind vergleichbar mit einer in ihren Auswirkungen nicht abschätzbaren chemischen Reaktion beim Mischen zweier unbekannter Chemikalien. Während in der Chemie strenge Regeln existieren, um Katastrophen zu verhindern, sind entsprechende Vorsichtsmaßnahmen in der Softwareentwicklung meistens nicht realisierbar, weil zu aufwändig.

In der Chemie ist die Mischung unbekannter Chemikalien aus Sicherheitsgründen verboten, in der Softwareentwicklung die Integration von Code mit unzureichend bekannten Eigenschaften nicht.