Zusammenfassung
Die Gestaltung von Software, die die Entwicklung mit einbezieht, erweist sich häufig als schwieriges und langwieriges Unterfangen. Insbesondere ergeben sich drei Problemfelder, für die Lösungen gefunden werden müssen:63
-
Beherrschung der Komplexität von Aufgabenstellung und Problemlösung,
-
Bewältigung der Dynamik von Anforderungen und Einsatzbedingungen,
-
Beteiligung betroffener Interessengruppen.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Vgl. Suhr/Suhr (1993), S. 96.
Im Rahmen der vorliegenden Ausführungen wird dem Begriffsverständnis von Pomberger und Blaschek gefolgt, die Software Engineering definieren als “die praktische Anwendung wissenschaftlicher Erkenntnisse für die wirtschaftliche Herstellung und den wirtschaftlichen Einsatz qualitativ hochwertiger Software”. Pomberger/Blaschek (1993), S. 3. Alternative Abgrenzungen finden sich z.B. bei Boehm (1986), S. 13; Balzert (1989), S. 3.
So läßt sich Software z.B. auf der Basis einer elementaren Programmiersprache wie einer Assemblersprache oder einer höheren maschinenunabhängigen Sprache (z.B. PASCAL, C, BASIC, COBOL) entwickeln oder mit Hilfe von mächtigen, eher deklarativen Sprachen und Entwicklungsumgebungen bzw. -Systemen (z.B. 4GL-Systeme).
Vgl. Huber (1989), S. 9.
Vgl. z.B. Suhr/Suhr (1993), S. 88.
Eine detaillierte Übersicht über die Qualitätsmerkmale von Softwareprodukten bietet Balzert (1989), S. lOff.
Zur Wirtschaftlichkeit der Software-Produktion siehe z.B. Boehm (1986), S. 141ff.
Vgl. Hesse/Merbeth/Frölich (1992), S. 30; Balzert (1989), S. 17.
Ein Überblick über unterschiedliche Phasenkonzepte findet sich bei Balzert (1989), S. 469.
Durch das Wasserfall-Modell erfährt das klassische, streng sequentielle Vorgehen des Life-Cycle-Konzeptes eine Aufweichung, indem Rückkopplungen zwischen den einzelnen Phasen nicht ausgeschlossen werden. Rücksprünge über mehrere Phasen hinweg sowie die damit verbundenen Wiederholungsaktivitäten werden allerdings auch hier nur in Ausnahmefällen empfohlen und sind möglichst ganz zu vermeiden. Vgl. Pomberger/Blaschek (1993), S. 24. Teilweise werden die Begriffe Life-Cycle-Modell und Wasserfallmodell auch synonym verwendet. Vgl. Goldammer (1994), S. 253.
Quelle: Hesse/Merbeth/Frölich (1992), S. 35.
Siehe z.B. Boehm (1986), S. 30.
Vgl. Koreimann (1992), S. 54ff.
Zum Modulbegriff vgl. Sommerville (1988), S. 12.
Eine Übersicht über gebräuchliche Spezifikationstechniken liefern z.B. Österle (1981), S. 88ff. und Koreimann (1992), S. 172ff. Koreimann unterscheidet grob zwischen eher funktionsorientierten und eher datenorientierten sowie zwischen allgemeinen und programmnahen Beschreibungsformen.
Vgl. Pomberger/Blaschek (1993), S. 22.
Vgl. Suhr/Suhr (1993), S. 97.
Vgl. Pomberger/Blaschek (1993), S. 22.
Vgl. Hesse/Merbeth/Frölich (1992), S. 65.
Vgl. Suhr/Suhr (1993), S. 103. Allerdings soll der Prototyp weder Anforderungsdefinition (Pflichtenheft) noch Systemspezifikation als Dokumente ersetzen, sondern lediglich ergänzen. Vgl. Goldammer (1994), S. 254.
Z.B. bei der Gestaltung der Benutzungsoberfläche [User-Interface-Prototyping]. Vgl. Pomberger/Blaschek (1993), S. 25.
Vgl. Hesse/Merbeth/Frölich (1992), S. 65.
Vgl. Hesse/Merbeth/Frölich (1992), S. 66.
Vgl. hierzu auch die Ausführungen zur iterativen (Abschnitt 7.1.3) und evolutionären (Abschnitt 7.1.4) Systemgestaltung.
Vgl. Abschnitt 6.2.1.
Vgl. die Ausführungen im vorhergehenden Abschnitt 7.1.2.
Vgl. Hildebrand (1990), S. 89; Suhr/Suhr (1993), S. 108f.
In Anlehnung an: Boehm (1988).
Vgl. Suhr/Suhr (1993), S. 109ff.
Dieses Argument weist insbesondere für den Managementbereich hohe Relevanz auf — nicht zuletzt da sich im betrieblichen Management oftmals eine mangelnde rechnerspezifische Qualifikation im Vergleich mit anderen Mitarbeitergruppen konstatieren läßt, wie durch empirische Untersuchungen belegt wird. Vgl. Oetinger (1988), S. 183.
Vgl. Hesse/Merbeth/Frölich (1992), S. 64. Die in dieser Phase anfallenden Tätigkeiten umfassen ein Spektrum, das von der punktuellen Fehlerbehebung bis zu umfangreichen Weiterentwicklungs- und Reimplementierungsmaßnahmen reicht. Siehe auch die Ausführungen zur Wartungsphase in Abschnitt 7.1.1.
Vgl. Koslowski (1988), S. 170; ebenso Knittel (1995), S. 39.
Vgl. Hesse/Merbeth/Frölich (1992), S. 68.
So z.B. Koslowski, der unterschiedliche zyklische Softwareentwicklungsmethodiken unter den Oberbegriff prozeßorientierte Systementwicklung subsummiert. Siehe Koslowski (1988), S. 150ff.
Vgl. Knittel (1995), S. 39. Eine Endversion im Sinne eines “fertigen Produktes” wird jedoch nicht erreicht. Vielmehr sind es stabile Zwischenversionen, die bis zum nächsten aufgetretenen Änderungsbedarf und der resultierenden neuen Version den aktuellen Stand der Entwicklung repräsentieren.
Vgl. Koslowski (1988), S. 171.
Hildebrand legt einen umfangreichen Katalog mit verschiedenen Tool- bzw. Werkzeugkategorien vor, die bei der Entwicklung von Anwendungsprogrammen zum Einsatz gelangen können. Vgl. Hildebrand (1990), S. 140ff.
Gelangen z.B. CASE-Werkzeuge und -Entwicklungsumgebungen zum Einsatz, dann sollen diese eine Versions- und Variantenverwaltung aktiv unterstützen. Vgl. Hesse/Merbeth/Frölich (1992), S. 264ff.
Bullinger, Koll und Niemeier charakterisieren die Produkteinführung bei Systemen für das Top-Management als “Netz evolutionärer Ausbreitungs- und Implementierungszyklen”. Bullinger/Koll/Niemeier (1993), S. 75.
Vgl. Knittel (1995), S. 27. Im Managementbereich wird diese Fehlentwicklung eher verstärkt durch die Möglichkeit zur individuellen Selbstbestimmung von Arbeitsabläufen sowie durch die Unwilligkeit vieler Manager, Zeit für die Auseinandersetzung mit neuen Techniken zu opfern.
Vgl Oetinger (1988), S. 43f.
Vgl. Koslowski (1988), S. 46.
Unter Betroffene können sowohl die späteren Anwender bzw. Benutzer eines Softwaresystems als auch externe Betroffene — z.B. Bürger einer Stadt im Zuge der Erstellung eines städtischen Informationssystems — verstanden werden. Vgl. Koslowski (1988), S. 31ff. Hier soll vornehmlich die Beteiligung der späteren Anwender bei der Systementwicklung im Vordergrund stehen.
Vgl. Mumford/Welter (1984), S. 65ff.
Vgl. Mumford/Welter (1984), S. 75.
Häufig tritt das Management nicht nur als späterer Anwender auf, sondern vereinigt gleichzeitig die Rollen des Auftraggebers und des Gespächspartners bei Software-Entscheidungen in sich. Dadurch ist das Verhältnis zur neuen Software oftmals eher durch Wirtschaftlichkeitsaspekte denn durch Benutzersichtweisen geprägt. Vgl. Oetinger (1988), S. 183 und S. 193.
Vgl. Abschnitt 6.2.1.
Als besonders vielversprechend für den Managementsektor erweisen sich Konzepte, die eine Zusammenführung von Versionenkonzept und Benutzerbeteiligung anstreben. Vgl. hierzu die Ausführungen zu STEPS (Softwaretechnik für evolutionäre partizipative Systementwicklung) z.B. bei Knittel (1995), S. 66ff.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 1997 Springer-Verlag Berlin Heidelberg
About this chapter
Cite this chapter
Gluchowski, P., Gabriel, R., Chamoni, P. (1997). Systemgestaltung von Management Support Systemen. In: Management Support Systeme. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-662-08466-3_7
Download citation
DOI: https://doi.org/10.1007/978-3-662-08466-3_7
Publisher Name: Springer, Berlin, Heidelberg
Print ISBN: 978-3-540-61782-2
Online ISBN: 978-3-662-08466-3
eBook Packages: Springer Book Archive