Softwaretechnik (eBook)

Foreword 6
Geleitwort zur 1. Auflage 8
Vorwort zur 2. Auflage 9
Inhalt 10
1. Einführung 14
1.1 Wovon dieses Buch handelt 14
1.2 Wer wir sind 15
1.3 Wer das Buch lesen sollte 15
1.4 Wie das Buch gegliedert ist 15
2. Projektmodell 18
2.1 Struktur des Vorgehens 18
2.2 Beteiligte und ihre Rollen 20
2.3 Phasen und Ergebnisse 22
2.4 Stufen und Iterationen 30
2.5 Die richtige Balance 31
3. Systemspezifikation 34
3.1 Definition und Ziele der Spezifikation 36
3.2 Spezifikationsmethoden 39
3.3 Die Zusammenarbeit mit den Anwendern 42
3.4 Praktisches Handwerk in der Spezifikation 45
3.5 Form, Sprache und Inhalt 54
3.6 Merksatz 60
4. Bausteine und Spezifikation 62
4.1 Übersicht und Einordnung 62
4.2 Projektgrundlagen 65
4.3 Abläufe und Funktionen 65
4.4 Datenmodell und Datentypen 68
4.5 Benutzerschnittstelle 71
4.6 Alt- und Nachbarsysteme 74
4.7 Übergreifendes 76
4.8 Ergänzende Bausteine 76
5. Ergonomische Gestaltung von Dialogoberflächen 78
5.1 Aufgaben- und benutzerorientierte Dialoggestaltung 78
5.2 Prinzipien der ergonomsichen Dialoggestaltung 88
5.3 Gestaltungsrichtlinien 98
6. Software-Architektur 102
6.1 Was ist gute Software-Architektur? 105
6.2 Trennung der Zuständigkeiten 108
6.3 Datenabstraktion 110
6.4 Komponenten 112
6.5 Schnittstellen (Vertiefung) 114
6.6 Muster 117
6.7 Das Schichtenmodell betrieblicher Informationssysteme 119
6.8 Verteilte Systeme 125
7. Datentypen 128
7.1 Was ist ein Datentyp? 129
7.2 Der Baukasten der Datentypen 133
7.3 Externe Darstellungen 136
7.4 Fachliche Datentypen 138
7.5 Initialisierung und Konsistenz 141
7.6 Fachliche Datentypen in Spezifikation und Konstruktion 142
7.7 Konstruktionsbeispiel: Datum 144
7.8 Konstruktionsbeispiel: Enumerationstypen 146
7.9 Administration 148
8. Anwendungsserver 150
8.1 Transaktionssysteme 150
8.2 Aufgaben eines Anwendungsservers 152
8.3 Realisierung von Transaktionsprogrammen 159
8.4 Beispiel CICS 163
8.5 Beispiel J2EE - Servlets und JSP 170
8.6 Beispiel J2EE - EJB 173
8.7 Ausblick 177
9. Software-Renovierung 178
9.1 Begriffe 179
9.2 Ausgangssituation für Software-Renovierung 180
9.3 Das Vorgehensmodell der Software-Renovierung 182
9.4 Migration 185
9.5 Techniken und Werkzeuge 188
9.6 Teamgestaltung 199
10. Wiederverwendung 202
10.1 Wiederverwendung - ein Mythos des Software Engineering 202
10.2 Begriffe und Grundlagen 203
10.3 Fallstudien zur Wiederverwendung 209
10.4 Ökonomische Analyse der Wiederverwendung 219
10.5 Rahmenbedingungen und Status quo 221
10.6 Softwaretechnische Kriterien für die Bewertung von Projektvorhaben 223
10.7 Wiederverwendbarmachung: Anforderung, Kosten und Maßnahmen 225
10.8 Softwaretechnische Leitlinien 228
11. Software-Entwicklungsumgebungen 230
11.1 Welche Werkzeuge gibt es? 230
11.2 Was ist eine SEU? 238
11.3 Welche Bausteine hat eine SEU? 241
11.4 Wie baut man eine SEU? 247
12. Konfigurationsmanagement 256
12.1 Die vier Säulen des Konfigurationsmanagement 257
12.2 Wie bringt man Konfigurationsmanagement in ein Projekt? 274
12.3 Ausblick 283
12.4 Epilog 284
13. Qualitätsmanagement 286
13.1 Das Beispielprojekt 286
13.2 Der Projektverlauf im Überblick 287
13.3 Rollen im Qualitätsmanagement 288
13.4 Qualitätsziele und -kriterien vereinbaren 288
13.5 Exkurs: "Wir haben keine Zeit für so was" 292
13.6 Qualitätsmaßnahmen planen und durchführen 293
13.7 Die Konsequenzen ziehen 297
13.8 Worauf es ankommt 299
14. Testen 300
14.1 Warum testen? 300
14.2 Teststufen 303
14.3 Testfälle und Testarten 313
14.4 Organisation und Technik 321
14.5 Testmanagement 328
14.6 Fazit 332
15. Projektmanagement 334
15.1 Einleitung 334
15.2 Projektplanung und Aufwandskalkulation 336
15.3 Projektorganisation 347
15.4 Menschen machen Projekte - der Faktor Peopleware 350
Literatur 356
Herausgeber und Autoren 360
Register 364

4 Bausteine der Spezifikation (S. 49-50)
von Wolfgang Krug und Johannes Siedersleben

? Aus welchen Bausteinen besteht eine Spezifikation und wie schreibt man sie auf?

4.1 Ubersicht und Einordnung

Die Spezifikation ist der Bauplan fuer das System und sie sagt dem Benutzer, was ihn erwartet. Wie schreibt man so etwas auf? Diese Frage ist so alt wie die Softwaretechnik selbst, und sie ist immer noch nicht beantwortet. Wir begegnen zwei Trends, die wir fuer gefaehrlich halten: Erstens die Beschraenkung der Spezifikation auf Bilder wie z.B. Klassendiagramme und zweitens der Verzicht auf die Spezifikation insgesamt.

Bilder sind hilfreich und ein Bild sagt bekanntlich mehr als tausend Worte. Aber tausend Bilder sagen weniger als hundert Seiten sorgfaeltig geschriebene und sinnvoll illustrierte Dokumentation. Die Beschraenkung auf Bilder ist gefaehrlich: Am Anfang erscheint alles einfach und uebersichtlich, aber am Ende droht das Chaos. Wir brauchen Bilder, das ist selbstverstaendlich, aber wir vermeiden bewusst den Irrweg, den viele Werkzeuge nahe legen: naive Reduzierung auf die Graphik und weitgehender Verzicht auf Text. Software wird geschrieben, nicht gezeichnet (vgl. [Den93]).

Der vollstaendige Verzicht auf die Spezifikation, wie er im XP1)-Umfeld gelegentlich propagiert wird, ist mit Sicherheit ein Irrweg und diskreditiert andere wertvolle XP-Elemente (wie etwa die Idee des permanenten Tests). Nun gibt es neben der grafiklastigen Spezifikation und dem voelligen Verzicht eine weitere Gefahr, naemlich die der Überspezifikation. Viele Projekte haben sich buchstaeblich zu Tode spezifiziert, Berge von Dokumenten erstellt, die keiner liest, die fuer den Anwender und den Programmierer unverstaendlich und schon zum Erstellungszeitpunkt veraltet sind. Dieses Kapitel beschreibt einen Mittelweg. Wir sind der Ansicht, dass man wichtige Dinge aufschreiben muss, denn nur was aufgeschrieben ist, kann man auch verbindlich kommunizieren, und erst beim Niederschreiben werden Unstimmigkeiten und Luecken offenbar ± das wei[02da] jeder, der eine Diplomarbeit verfasst hat. Unabhaengig von jeder Methode gelten zwei Regeln: Erstens erstellen wir nur solche Papiere, die auch ihren Leser finden, denn alles andere ist vertane Zeit. Und zweitens sind nur kurze Papiere gute Papiere. Die akzeptable Laenge haengt natuerlich von der Zielgruppe ab: Der Manager liest am liebsten nur eine Seite, maximal drei, doch die Spezifikation der Anwendungsfaelle eines Systems darf auch 100 Seiten dick sein ± aber bitte keine tausend!

Dieses Kapitel beschreibt die Bausteine der Spezifikation. Das sind nicht weniger als insgesamt 17 Stueck. Sie sind entstanden im Rahmen einer Analyse von mehreren in unserem Haus durchgefuehrten Projekten und dienen als Fahrplan fuer die Erstellung von Spezifikationen. Zwar haengen die Bausteine zum Teil voneinander ab, aber gerade der Bausteincharakter macht es moeglich, die verschiedenen Themen zu entzerren und zeitlich gestaffelt zu bearbeiten. Insofern ist der Bausteingedanke kompatibel zu verschiedenen Vorgehensmodellen.

Jeder Baustein ist eine Anleitung fuer einen bestimmten Teil der Spezifikation; die Liste der Bausteine selbst dient als Checkliste. Das Ganze ist zu verstehen als Baukasten: Jedes Projekt entscheidet, welche Bausteine in welcher Tiefe ausgefuehrt werden. Alle Bausteine sind in ausfuehrlicher Form im Intranet von sd&m verfuegbar. Gro[02da]e Projekte sind erst machbar, wenn sie in ueberschaubare Teilprojekte aufgeteilt sind. Es gibt keine belastbaren Angaben zur Überschaubarkeit, aber als ganz grobe Richtlinie nennen wir die Zahl von sieben Bearbeiterjahren (Sieben spielt auch hier eine besondere Rolle). Projekte, die wesentlich groe[02da]er sind, sollte man aufteilen.