Sie sind hier
E-Book

Softwaretechnik

VerlagCarl Hanser Fachbuchverlag
Erscheinungsjahr2003
Seitenanzahl369 Seiten
ISBN9783446225299
FormatPDF
KopierschutzWasserzeichen/DRM
GerätePC/MAC/eReader/Tablet
Preis35,99 EUR
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.

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.

Kaufen Sie hier:

Horizontale Tabs

Kapitelübersicht
  1. Inhalt
  2. 1. Einführung (Siedersleben)
  3. 2. Projektmodell (Scheidle / Taubner)
  4. 3. Systemspezifikation (Beer)
  5. 4. Bausteine und Spezifikation (Krug / Siedersleben)
  6. 5. Ergonomische Gestaltung von Dialogoberflächen (Strauß)
  7. 6. Software-Architektur (Siedersleben)
  8. 7. Datentypen (Siedersleben)
  9. 8. Anwendungsserver (Hess)
  10. 9. Software-Renovierung (Keipinger)
  11. 10. Wiederverwendung (Stützle)
  12. 11. Software-Entwicklungsumgebungen (Detering-Meyer)
  13. 12. Konfigurationsmanagement (Eilfeld / Schaal / Schekelmann)
  14. 13. Qualitätsmanagement (Mieth)
  15. 14. Testen (Schaumann)
  16. 15. Projektmanagement (Lannes)
  17. Literatur, Herausgeber und Autoren, Register
Leseprobe
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.
Inhaltsverzeichnis
Foreword6
Geleitwort zur 1. Auflage8
Vorwort zur 2. Auflage9
Inhalt10
1. Einführung14
1.1 Wovon dieses Buch handelt14
1.2 Wer wir sind15
1.3 Wer das Buch lesen sollte15
1.4 Wie das Buch gegliedert ist15
2. Projektmodell18
2.1 Struktur des Vorgehens18
2.2 Beteiligte und ihre Rollen20
2.3 Phasen und Ergebnisse22
2.4 Stufen und Iterationen30
2.5 Die richtige Balance31
3. Systemspezifikation34
3.1 Definition und Ziele der Spezifikation36
3.2 Spezifikationsmethoden39
3.3 Die Zusammenarbeit mit den Anwendern42
3.4 Praktisches Handwerk in der Spezifikation45
3.5 Form, Sprache und Inhalt54
3.6 Merksatz60
4. Bausteine und Spezifikation62
4.1 Übersicht und Einordnung62
4.2 Projektgrundlagen65
4.3 Abläufe und Funktionen65
4.4 Datenmodell und Datentypen68
4.5 Benutzerschnittstelle71
4.6 Alt- und Nachbarsysteme74
4.7 Übergreifendes76
4.8 Ergänzende Bausteine76
5. Ergonomische Gestaltung von Dialogoberflächen78
5.1 Aufgaben- und benutzerorientierte Dialoggestaltung78
5.2 Prinzipien der ergonomsichen Dialoggestaltung88
5.3 Gestaltungsrichtlinien98
6. Software-Architektur102
6.1 Was ist gute Software-Architektur?105
6.2 Trennung der Zuständigkeiten108
6.3 Datenabstraktion110
6.4 Komponenten112
6.5 Schnittstellen (Vertiefung)114
6.6 Muster117
6.7 Das Schichtenmodell betrieblicher Informationssysteme119
6.8 Verteilte Systeme125
7. Datentypen128
7.1 Was ist ein Datentyp?129
7.2 Der Baukasten der Datentypen133
7.3 Externe Darstellungen136
7.4 Fachliche Datentypen138
7.5 Initialisierung und Konsistenz141
7.6 Fachliche Datentypen in Spezifikation und Konstruktion142
7.7 Konstruktionsbeispiel: Datum144
7.8 Konstruktionsbeispiel: Enumerationstypen146
7.9 Administration148
8. Anwendungsserver150
8.1 Transaktionssysteme150
8.2 Aufgaben eines Anwendungsservers152
8.3 Realisierung von Transaktionsprogrammen159
8.4 Beispiel CICS163
8.5 Beispiel J2EE - Servlets und JSP170
8.6 Beispiel J2EE - EJB173
8.7 Ausblick177
9. Software-Renovierung178
9.1 Begriffe179
9.2 Ausgangssituation für Software-Renovierung180
9.3 Das Vorgehensmodell der Software-Renovierung182
9.4 Migration185
9.5 Techniken und Werkzeuge188
9.6 Teamgestaltung199
10. Wiederverwendung202
10.1 Wiederverwendung - ein Mythos des Software Engineering202
10.2 Begriffe und Grundlagen203
10.3 Fallstudien zur Wiederverwendung209
10.4 Ökonomische Analyse der Wiederverwendung219
10.5 Rahmenbedingungen und Status quo221
10.6 Softwaretechnische Kriterien für die Bewertung von Projektvorhaben223
10.7 Wiederverwendbarmachung: Anforderung, Kosten und Maßnahmen225
10.8 Softwaretechnische Leitlinien228
11. Software-Entwicklungsumgebungen230
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. Konfigurationsmanagement256
12.1 Die vier Säulen des Konfigurationsmanagement257
12.2 Wie bringt man Konfigurationsmanagement in ein Projekt?274
12.3 Ausblick283
12.4 Epilog284
13. Qualitätsmanagement286
13.1 Das Beispielprojekt286
13.2 Der Projektverlauf im Überblick287
13.3 Rollen im Qualitätsmanagement288
13.4 Qualitätsziele und -kriterien vereinbaren288
13.5 Exkurs: "Wir haben keine Zeit für so was"292
13.6 Qualitätsmaßnahmen planen und durchführen293
13.7 Die Konsequenzen ziehen297
13.8 Worauf es ankommt299
14. Testen300
14.1 Warum testen?300
14.2 Teststufen303
14.3 Testfälle und Testarten313
14.4 Organisation und Technik321
14.5 Testmanagement328
14.6 Fazit332
15. Projektmanagement334
15.1 Einleitung334
15.2 Projektplanung und Aufwandskalkulation336
15.3 Projektorganisation347
15.4 Menschen machen Projekte - der Faktor Peopleware350
Literatur356
Herausgeber und Autoren360
Register364

Weitere E-Books zum Thema: Software - Betriebssysteme - Anwenderprogramme

Erfolgsfaktor Unternehmenssteuerung

E-Book Erfolgsfaktor Unternehmenssteuerung
Kennzahlen, Instrumente, Praxistipps Format: PDF

Als sich in den Jahren 2000/2001 die Boomphase in der Druck- und Medienindustrie abschwächte, standen viele erfolgsverwöhnte - ternehmen der Branche dem daraus resultierenden wirtschaftlichen Druck…

Dauerhafter Erfolg mit Business Software

E-Book Dauerhafter Erfolg mit Business Software
Zehn Jahre Fallstudien nach der eXperience Methodik Format: PDF

Viele der heutigen Unternehmensleistungen sind nur durch den Einsatz leistungsfähiger Business Software möglich. Aber ERP- und CRM-Systeme, Online-Shops und E Procurement-Lösungen sind anspruchsvolle…

Statistik für Ökonomen

E-Book Statistik für Ökonomen
Datenanalyse mit R und SPSS Format: PDF

Die Autoren erläutern in einer anschaulichen, anwendungsorientierten und kompakten Darstellung alle elementaren statistischen Verfahren, die in der Ökonomie angewendet werden - ergänzt durch…

Kennzahlen in der IT

E-Book Kennzahlen in der IT
Werkzeuge für Controlling und Management Format: PDF

Dieses Buch entwirft ein zeitgemäßes Kennzahlenverständnis für den IT-Bereich. Vor dem Hintergrund der Balanced Scorecard werden die Ansätze in verschiedenen Teilbereichen sowie unterschiedliche…

Referenzmodelle für IT-Governance

E-Book Referenzmodelle für IT-Governance
Methodische Unterstützung der Unternehmens-IT mit COBIT, ITIL & Co Format: PDF

Das Buch zeigt, wie die Aufgaben der IT-Governance durch Best-Practice-Referenzmodelle sowie internationale Normen und Standards methodisch zu unterstützen und zu bewältigen sind, und gibt einen…

Weitere Zeitschriften

Atalanta

Atalanta

Atalanta ist die Zeitschrift der Deutschen Forschungszentrale für Schmetterlingswanderung. Im Atalanta-Magazin werden Themen behandelt wie Wanderfalterforschung, Systematik, Taxonomie und Ökologie. ...

BONSAI ART

BONSAI ART

Auflagenstärkste deutschsprachige Bonsai-Zeitschrift, basierend auf den renommiertesten Bonsai-Zeitschriften Japans mit vielen Beiträgen europäischer Gestalter. Wertvolle Informationen für ...

Courier

Courier

The Bayer CropScience Magazine for Modern AgriculturePflanzenschutzmagazin für den Landwirt, landwirtschaftlichen Berater, Händler und generell am Thema Interessierten, mit umfassender ...

die horen

die horen

Zeitschrift für Literatur, Kunst und Kritik."...weil sie mit großer Aufmerksamkeit die internationale Literatur beobachtet und vorstellt; weil sie in der deutschen Literatur nicht nur das Neueste ...

Dr. med. Mabuse

Dr. med. Mabuse

Zeitschrift für alle Gesundheitsberufe Seit über 40 Jahren sorgt die Zeitschrift Dr. med. Mabuse für einen anderen Blick auf die Gesundheits- und Sozialpolitik. Das Konzept einer Zeitschrift ...

IT-BUSINESS

IT-BUSINESS

IT-BUSINESS ist seit mehr als 25 Jahren die Fachzeitschrift für den IT-Markt Sie liefert 2-wöchentlich fundiert recherchierte Themen, praxisbezogene Fallstudien, aktuelle Hintergrundberichte aus ...