Gerlich 111 Thesen zur erfolgreichen Softwareentwicklung

Argumente und Entscheidungshilfen für Manager. Konzepte und Anleitungen für Praktiker
2005
ISBN: 978-3-540-27344-8
Verlag: Springer Berlin Heidelberg
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 522 Seiten

Reihe: Xpert.press

Ziel dieses Buches ist es, Managern Argumente und Entscheidungshilfen für die Einführung effizienter Techniken der Softwareentwi- lung zu geben, und Praktiker von der Notwendigkeit effizienter Softwaree- wicklung zu überzeugen und Wege zur erfolgreichen - wendung aufzuzeigen. Unter 'effizienter Softwareentwicklung' verstehen wir die - setzung von Anforderungen in 'qualitativ hochwertige' Software zu 'angemessenem' Preis innerhalb 'angemessener' Zeit. 'Qualitativ hochwertig' steht für fehlerfrei, zuverlässig, robust und voll den Anforderungen entsprechend. Unter 'angemessen' verstehen wir minimale Komplexität bei voller Abdeckung der - forderungen, bezahlbar und kurzfristig verfügbar. Im ersten Teil dieses Buches (Kap. 2 - 5) führen wir den Leser hin zum 'automatischen Softwareproduktionsprozess', durch P- sentation von Thesen und Analysen. Anleitungen und Beispiele folgen im zweiten Teil (Kap. 6 und 7). Wir schließen mit Betra- tungen zur gesellschaftspolitischen Relevanz einer Technologie, die auf Automation beruht (Kap. 8). Wie in anderen Bereichen, in denen Automation bereits an- wendet wird, haben automatische Softwareproduktionsprozesse Einfluss auf die Arbeitsplätze. Präziser ausgedrückt, es fallen - stimmte Arten von Arbeitsplätzen weg, während andere entstehen. Für Manager und Entwickler, aber auch Ausbilder, ist es wichtig, sich frühzeitig auf die Möglichkeiten und Folgen dieser Technologie einzustellen. Zur Zeit wird durch 'Outsourcing', 'Nearshoring' oder 'Offs- ring' versucht, die Softwareentwicklungskosten zu senken. 'Au- mation' in der Softwareentwicklung geht darüber hinaus. Nicht nur Kosten sinken, auch Entwicklungszeit und -risiken, die Flexibilität ? Vorwort VII ? ? erhöht sich, und Know-how muss nicht nach außen weitergegeben werden.

Autoren/Hrsg.

Gerlich, Rainer

Inhaltsverzeichnis

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

Leseproben

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.