Softwaretechnik
Praxiswissen für Softwareingenieure
2nd Edition
Published on 24. October 2002
350 pages
978-3-446-22529-9 (ISBN)
Description
Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche Projektkatastrophen haben komplizierte, oft unternehmenspolitische Ursachen. Häufig aber liegt der Grund des Scheiterns in der Missachtung der Grundregeln der Softwaretechnik. Wer diese Regeln kennt und befolgt, erhöht nachhaltig die Wahrscheinlichkeit des Projekterfolgs.
Was macht ein erfolgreiches Software-Projekt aus? Diese Frage beantworten 15 erfahrene Praktiker des Softwarehauses sd&m. Sie behandeln folgende Themen:
- Das sd&m-Projektmodell
- Systemspezifikation
- Bausteine der Spezifikation
- Ergonomie von Dialogoberflächen
- Software-Architektur
- Datentypen
- Anwendungsserver
- Software-Renovierung
- Wiederverwendung
- Software-Entwicklungsumgebungen
- Konfigurationsmanagement
- Qualitätsmanagement
- Testen
- Projektmanagement
Aufbauend auf Grundkenntnissen der Informatik führt das Buch ein in die praktischen Aspekte der Softwaretechnik und bietet Berufseinsteigern und Studenten das Praxiswissen für eine erfolgreiche Arbeit in Software-Projekten. Dem Praktiker gibt es neue Impulse.
Was macht ein erfolgreiches Software-Projekt aus? Diese Frage beantworten 15 erfahrene Praktiker des Softwarehauses sd&m. Sie behandeln folgende Themen:
- Das sd&m-Projektmodell
- Systemspezifikation
- Bausteine der Spezifikation
- Ergonomie von Dialogoberflächen
- Software-Architektur
- Datentypen
- Anwendungsserver
- Software-Renovierung
- Wiederverwendung
- Software-Entwicklungsumgebungen
- Konfigurationsmanagement
- Qualitätsmanagement
- Testen
- Projektmanagement
Aufbauend auf Grundkenntnissen der Informatik führt das Buch ein in die praktischen Aspekte der Softwaretechnik und bietet Berufseinsteigern und Studenten das Praxiswissen für eine erfolgreiche Arbeit in Software-Projekten. Dem Praktiker gibt es neue Impulse.
Reviews / Votes
"Ein herausragendes Werk, um sich Praxiswissen für erfolgreiche Projektarbeit anzueignen." MaschinenmarktMore details
Other editions
Additional editions
Book
10/2002
2nd Edition
Hanser
€44.90
Article exhausted; check different version
Persons
Content
1 - Foreword [Seite 6]
2 - Geleitwort zur 1. Auflage [Seite 8]
3 - Vorwort zur 2. Auflage [Seite 9]
4 - Inhalt [Seite 10]
5 - 1. Einführung [Seite 14]
5.1 - 1.1 Wovon dieses Buch handelt [Seite 14]
5.2 - 1.2 Wer wir sind [Seite 15]
5.3 - 1.3 Wer das Buch lesen sollte [Seite 15]
5.4 - 1.4 Wie das Buch gegliedert ist [Seite 15]
6 - 2. Projektmodell [Seite 18]
6.1 - 2.1 Struktur des Vorgehens [Seite 18]
6.2 - 2.2 Beteiligte und ihre Rollen [Seite 20]
6.3 - 2.3 Phasen und Ergebnisse [Seite 22]
6.4 - 2.4 Stufen und Iterationen [Seite 30]
6.5 - 2.5 Die richtige Balance [Seite 31]
7 - 3. Systemspezifikation [Seite 34]
7.1 - 3.1 Definition und Ziele der Spezifikation [Seite 36]
7.2 - 3.2 Spezifikationsmethoden [Seite 39]
7.3 - 3.3 Die Zusammenarbeit mit den Anwendern [Seite 42]
7.4 - 3.4 Praktisches Handwerk in der Spezifikation [Seite 45]
7.5 - 3.5 Form, Sprache und Inhalt [Seite 54]
7.6 - 3.6 Merksatz [Seite 60]
8 - 4. Bausteine und Spezifikation [Seite 62]
8.1 - 4.1 Übersicht und Einordnung [Seite 62]
8.2 - 4.2 Projektgrundlagen [Seite 65]
8.3 - 4.3 Abläufe und Funktionen [Seite 65]
8.4 - 4.4 Datenmodell und Datentypen [Seite 68]
8.5 - 4.5 Benutzerschnittstelle [Seite 71]
8.6 - 4.6 Alt- und Nachbarsysteme [Seite 74]
8.7 - 4.7 Übergreifendes [Seite 76]
8.8 - 4.8 Ergänzende Bausteine [Seite 76]
9 - 5. Ergonomische Gestaltung von Dialogoberflächen [Seite 78]
9.1 - 5.1 Aufgaben- und benutzerorientierte Dialoggestaltung [Seite 78]
9.2 - 5.2 Prinzipien der ergonomsichen Dialoggestaltung [Seite 88]
9.3 - 5.3 Gestaltungsrichtlinien [Seite 98]
10 - 6. Software-Architektur [Seite 102]
10.1 - 6.1 Was ist gute Software-Architektur? [Seite 105]
10.2 - 6.2 Trennung der Zuständigkeiten [Seite 108]
10.3 - 6.3 Datenabstraktion [Seite 110]
10.4 - 6.4 Komponenten [Seite 112]
10.5 - 6.5 Schnittstellen (Vertiefung) [Seite 114]
10.6 - 6.6 Muster [Seite 117]
10.7 - 6.7 Das Schichtenmodell betrieblicher Informationssysteme [Seite 119]
10.8 - 6.8 Verteilte Systeme [Seite 125]
11 - 7. Datentypen [Seite 128]
11.1 - 7.1 Was ist ein Datentyp? [Seite 129]
11.2 - 7.2 Der Baukasten der Datentypen [Seite 133]
11.3 - 7.3 Externe Darstellungen [Seite 136]
11.4 - 7.4 Fachliche Datentypen [Seite 138]
11.5 - 7.5 Initialisierung und Konsistenz [Seite 141]
11.6 - 7.6 Fachliche Datentypen in Spezifikation und Konstruktion [Seite 142]
11.7 - 7.7 Konstruktionsbeispiel: Datum [Seite 144]
11.8 - 7.8 Konstruktionsbeispiel: Enumerationstypen [Seite 146]
11.9 - 7.9 Administration [Seite 148]
12 - 8. Anwendungsserver [Seite 150]
12.1 - 8.1 Transaktionssysteme [Seite 150]
12.2 - 8.2 Aufgaben eines Anwendungsservers [Seite 152]
12.3 - 8.3 Realisierung von Transaktionsprogrammen [Seite 159]
12.4 - 8.4 Beispiel CICS [Seite 163]
12.5 - 8.5 Beispiel J2EE - Servlets und JSP [Seite 170]
12.6 - 8.6 Beispiel J2EE - EJB [Seite 173]
12.7 - 8.7 Ausblick [Seite 177]
13 - 9. Software-Renovierung [Seite 178]
13.1 - 9.1 Begriffe [Seite 179]
13.2 - 9.2 Ausgangssituation für Software-Renovierung [Seite 180]
13.3 - 9.3 Das Vorgehensmodell der Software-Renovierung [Seite 182]
13.4 - 9.4 Migration [Seite 185]
13.5 - 9.5 Techniken und Werkzeuge [Seite 188]
13.6 - 9.6 Teamgestaltung [Seite 199]
14 - 10. Wiederverwendung [Seite 202]
14.1 - 10.1 Wiederverwendung - ein Mythos des Software Engineering [Seite 202]
14.2 - 10.2 Begriffe und Grundlagen [Seite 203]
14.3 - 10.3 Fallstudien zur Wiederverwendung [Seite 209]
14.4 - 10.4 Ökonomische Analyse der Wiederverwendung [Seite 219]
14.5 - 10.5 Rahmenbedingungen und Status quo [Seite 221]
14.6 - 10.6 Softwaretechnische Kriterien für die Bewertung von Projektvorhaben [Seite 223]
14.7 - 10.7 Wiederverwendbarmachung: Anforderung, Kosten und Maßnahmen [Seite 225]
14.8 - 10.8 Softwaretechnische Leitlinien [Seite 228]
15 - 11. Software-Entwicklungsumgebungen [Seite 230]
15.1 - 11.1 Welche Werkzeuge gibt es? [Seite 230]
15.2 - 11.2 Was ist eine SEU? [Seite 238]
15.3 - 11.3 Welche Bausteine hat eine SEU? [Seite 241]
15.4 - 11.4 Wie baut man eine SEU? [Seite 247]
16 - 12. Konfigurationsmanagement [Seite 256]
16.1 - 12.1 Die vier Säulen des Konfigurationsmanagement [Seite 257]
16.2 - 12.2 Wie bringt man Konfigurationsmanagement in ein Projekt? [Seite 274]
16.3 - 12.3 Ausblick [Seite 283]
16.4 - 12.4 Epilog [Seite 284]
17 - 13. Qualitätsmanagement [Seite 286]
17.1 - 13.1 Das Beispielprojekt [Seite 286]
17.2 - 13.2 Der Projektverlauf im Überblick [Seite 287]
17.3 - 13.3 Rollen im Qualitätsmanagement [Seite 288]
17.4 - 13.4 Qualitätsziele und -kriterien vereinbaren [Seite 288]
17.5 - 13.5 Exkurs: "Wir haben keine Zeit für so was" [Seite 292]
17.6 - 13.6 Qualitätsmaßnahmen planen und durchführen [Seite 293]
17.7 - 13.7 Die Konsequenzen ziehen [Seite 297]
17.8 - 13.8 Worauf es ankommt [Seite 299]
18 - 14. Testen [Seite 300]
18.1 - 14.1 Warum testen? [Seite 300]
18.2 - 14.2 Teststufen [Seite 303]
18.3 - 14.3 Testfälle und Testarten [Seite 313]
18.4 - 14.4 Organisation und Technik [Seite 321]
18.5 - 14.5 Testmanagement [Seite 328]
18.6 - 14.6 Fazit [Seite 332]
19 - 15. Projektmanagement [Seite 334]
19.1 - 15.1 Einleitung [Seite 334]
19.2 - 15.2 Projektplanung und Aufwandskalkulation [Seite 336]
19.3 - 15.3 Projektorganisation [Seite 347]
19.4 - 15.4 Menschen machen Projekte - der Faktor Peopleware [Seite 350]
20 - Literatur [Seite 356]
21 - Herausgeber und Autoren [Seite 360]
22 - Register [Seite 364]
2 - Geleitwort zur 1. Auflage [Seite 8]
3 - Vorwort zur 2. Auflage [Seite 9]
4 - Inhalt [Seite 10]
5 - 1. Einführung [Seite 14]
5.1 - 1.1 Wovon dieses Buch handelt [Seite 14]
5.2 - 1.2 Wer wir sind [Seite 15]
5.3 - 1.3 Wer das Buch lesen sollte [Seite 15]
5.4 - 1.4 Wie das Buch gegliedert ist [Seite 15]
6 - 2. Projektmodell [Seite 18]
6.1 - 2.1 Struktur des Vorgehens [Seite 18]
6.2 - 2.2 Beteiligte und ihre Rollen [Seite 20]
6.3 - 2.3 Phasen und Ergebnisse [Seite 22]
6.4 - 2.4 Stufen und Iterationen [Seite 30]
6.5 - 2.5 Die richtige Balance [Seite 31]
7 - 3. Systemspezifikation [Seite 34]
7.1 - 3.1 Definition und Ziele der Spezifikation [Seite 36]
7.2 - 3.2 Spezifikationsmethoden [Seite 39]
7.3 - 3.3 Die Zusammenarbeit mit den Anwendern [Seite 42]
7.4 - 3.4 Praktisches Handwerk in der Spezifikation [Seite 45]
7.5 - 3.5 Form, Sprache und Inhalt [Seite 54]
7.6 - 3.6 Merksatz [Seite 60]
8 - 4. Bausteine und Spezifikation [Seite 62]
8.1 - 4.1 Übersicht und Einordnung [Seite 62]
8.2 - 4.2 Projektgrundlagen [Seite 65]
8.3 - 4.3 Abläufe und Funktionen [Seite 65]
8.4 - 4.4 Datenmodell und Datentypen [Seite 68]
8.5 - 4.5 Benutzerschnittstelle [Seite 71]
8.6 - 4.6 Alt- und Nachbarsysteme [Seite 74]
8.7 - 4.7 Übergreifendes [Seite 76]
8.8 - 4.8 Ergänzende Bausteine [Seite 76]
9 - 5. Ergonomische Gestaltung von Dialogoberflächen [Seite 78]
9.1 - 5.1 Aufgaben- und benutzerorientierte Dialoggestaltung [Seite 78]
9.2 - 5.2 Prinzipien der ergonomsichen Dialoggestaltung [Seite 88]
9.3 - 5.3 Gestaltungsrichtlinien [Seite 98]
10 - 6. Software-Architektur [Seite 102]
10.1 - 6.1 Was ist gute Software-Architektur? [Seite 105]
10.2 - 6.2 Trennung der Zuständigkeiten [Seite 108]
10.3 - 6.3 Datenabstraktion [Seite 110]
10.4 - 6.4 Komponenten [Seite 112]
10.5 - 6.5 Schnittstellen (Vertiefung) [Seite 114]
10.6 - 6.6 Muster [Seite 117]
10.7 - 6.7 Das Schichtenmodell betrieblicher Informationssysteme [Seite 119]
10.8 - 6.8 Verteilte Systeme [Seite 125]
11 - 7. Datentypen [Seite 128]
11.1 - 7.1 Was ist ein Datentyp? [Seite 129]
11.2 - 7.2 Der Baukasten der Datentypen [Seite 133]
11.3 - 7.3 Externe Darstellungen [Seite 136]
11.4 - 7.4 Fachliche Datentypen [Seite 138]
11.5 - 7.5 Initialisierung und Konsistenz [Seite 141]
11.6 - 7.6 Fachliche Datentypen in Spezifikation und Konstruktion [Seite 142]
11.7 - 7.7 Konstruktionsbeispiel: Datum [Seite 144]
11.8 - 7.8 Konstruktionsbeispiel: Enumerationstypen [Seite 146]
11.9 - 7.9 Administration [Seite 148]
12 - 8. Anwendungsserver [Seite 150]
12.1 - 8.1 Transaktionssysteme [Seite 150]
12.2 - 8.2 Aufgaben eines Anwendungsservers [Seite 152]
12.3 - 8.3 Realisierung von Transaktionsprogrammen [Seite 159]
12.4 - 8.4 Beispiel CICS [Seite 163]
12.5 - 8.5 Beispiel J2EE - Servlets und JSP [Seite 170]
12.6 - 8.6 Beispiel J2EE - EJB [Seite 173]
12.7 - 8.7 Ausblick [Seite 177]
13 - 9. Software-Renovierung [Seite 178]
13.1 - 9.1 Begriffe [Seite 179]
13.2 - 9.2 Ausgangssituation für Software-Renovierung [Seite 180]
13.3 - 9.3 Das Vorgehensmodell der Software-Renovierung [Seite 182]
13.4 - 9.4 Migration [Seite 185]
13.5 - 9.5 Techniken und Werkzeuge [Seite 188]
13.6 - 9.6 Teamgestaltung [Seite 199]
14 - 10. Wiederverwendung [Seite 202]
14.1 - 10.1 Wiederverwendung - ein Mythos des Software Engineering [Seite 202]
14.2 - 10.2 Begriffe und Grundlagen [Seite 203]
14.3 - 10.3 Fallstudien zur Wiederverwendung [Seite 209]
14.4 - 10.4 Ökonomische Analyse der Wiederverwendung [Seite 219]
14.5 - 10.5 Rahmenbedingungen und Status quo [Seite 221]
14.6 - 10.6 Softwaretechnische Kriterien für die Bewertung von Projektvorhaben [Seite 223]
14.7 - 10.7 Wiederverwendbarmachung: Anforderung, Kosten und Maßnahmen [Seite 225]
14.8 - 10.8 Softwaretechnische Leitlinien [Seite 228]
15 - 11. Software-Entwicklungsumgebungen [Seite 230]
15.1 - 11.1 Welche Werkzeuge gibt es? [Seite 230]
15.2 - 11.2 Was ist eine SEU? [Seite 238]
15.3 - 11.3 Welche Bausteine hat eine SEU? [Seite 241]
15.4 - 11.4 Wie baut man eine SEU? [Seite 247]
16 - 12. Konfigurationsmanagement [Seite 256]
16.1 - 12.1 Die vier Säulen des Konfigurationsmanagement [Seite 257]
16.2 - 12.2 Wie bringt man Konfigurationsmanagement in ein Projekt? [Seite 274]
16.3 - 12.3 Ausblick [Seite 283]
16.4 - 12.4 Epilog [Seite 284]
17 - 13. Qualitätsmanagement [Seite 286]
17.1 - 13.1 Das Beispielprojekt [Seite 286]
17.2 - 13.2 Der Projektverlauf im Überblick [Seite 287]
17.3 - 13.3 Rollen im Qualitätsmanagement [Seite 288]
17.4 - 13.4 Qualitätsziele und -kriterien vereinbaren [Seite 288]
17.5 - 13.5 Exkurs: "Wir haben keine Zeit für so was" [Seite 292]
17.6 - 13.6 Qualitätsmaßnahmen planen und durchführen [Seite 293]
17.7 - 13.7 Die Konsequenzen ziehen [Seite 297]
17.8 - 13.8 Worauf es ankommt [Seite 299]
18 - 14. Testen [Seite 300]
18.1 - 14.1 Warum testen? [Seite 300]
18.2 - 14.2 Teststufen [Seite 303]
18.3 - 14.3 Testfälle und Testarten [Seite 313]
18.4 - 14.4 Organisation und Technik [Seite 321]
18.5 - 14.5 Testmanagement [Seite 328]
18.6 - 14.6 Fazit [Seite 332]
19 - 15. Projektmanagement [Seite 334]
19.1 - 15.1 Einleitung [Seite 334]
19.2 - 15.2 Projektplanung und Aufwandskalkulation [Seite 336]
19.3 - 15.3 Projektorganisation [Seite 347]
19.4 - 15.4 Menschen machen Projekte - der Faktor Peopleware [Seite 350]
20 - Literatur [Seite 356]
21 - Herausgeber und Autoren [Seite 360]
22 - Register [Seite 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.
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.
