%                                                          infospek.dem
% LaTeX package LJour2 1.0: demonstration file
% (c) Springer-Verlag HD
%----------------------------------------------------------------------
% Demo-article of Informatik Spektrum
% that starts on page 53, hence the page counter is set to that value.
%
% The article is written in German hence it calls for a pgljour2 format
% i.e. PostScript fonts, German hyphenation, LaTeX, two column layout.
%
% You can process it with a normal cljour2 format as well. Just ignore
% the error message upon startup and the bad linebreaks resulting
% from the wrong hyphenation table.
%
\documentstyle[deutsch]{pgljour2}
\makeatletter
% borrow a few things from the german.sty
\def\allowhyphens{\penalty\@M \hskip\z@skip}
\def\set@low@box#1{\setbox\tw@\hbox{,}\setbox\z@\hbox{#1}%
  \setbox\z@\hbox{\dimen@\ht\z@ \advance\dimen@ -\ht\tw@
      \lower\dimen@\box\z@}%
  \ht\z@\ht\tw@ \dp\z@\dp\tw@}
\def\save@sf@q#1{{\ifhmode \edef\@SF{\spacefactor\the\spacefactor}\else
  \let\@SF\empty \fi \leavevmode #1\@SF}}

\def\@glqq{\save@sf@q{\set@low@box{''\/}\box\z@\allowhyphens}}
\def\glqq{\protect\@glqq}
\def\@grqq{\save@sf@q{``\kern.07em}}
\def\grqq{\protect\@grqq}
\makeatother

\let\abstract=\relax
\let\keywords=\relax
\let\typeset=\relax
\def\labelitemi{$\bullet$}
\def\sectcounterend{.}
\def\CRC{\par\addvspace\baselineskip\noindent{\bf Computing Reviews
Classification:}\ignorespaces}
\journalname{Informatik-Spektrum}
\begin{document}
\title{Praxis des Software-Engineering -- heute und morgen}
\titlerunning{J.Witt: Praxis des Software-Engineering -- heute und
titlerunning -- heute und jdkfj djldfjk askljj
morgen}
\authorrunning{J.Witt: Praxis des Software-Engineering -- heute und
morgen}
\author{Jan Witt}
\institute{Digital-PCS Systemtechnik GmbH, M\"unchen}
\date{\vskip -12.85pt}
\maketitle

\setcounter{page}{53}

\begin{small}
\raggedleft\leavevmode\null\hfill\parfillskip=0pt
\vtop{\hbox{My nature is subdued}
\hbox{to what it works in,}
\hbox{like the dyer's hand.}\vskip\medskipamount
\hbox{(Shakespeare, Sonnet 111)}}\end{small}

\section*{T\"atigkeiten im Umfeld der Verfertigung und
Beschaffung von Software}

Allgemeiner Konsens besteht dar\"uber, da\ss{} es im Lebenslauf eines
\glqq St\"ucks Software\grqq{}, vom Wunsch bis zu seiner Verwirklichung,
von der Beschaffung bis zum Einsatz viele T\"atigkeiten gibt, die
irgendjemand ausf\"uhren mu\ss{}, z.B. die folgenden:

\begin{itemize}
\item Herbeiw\"unschen (Desiderata)
\item Fordern (Anforderungen, Requirements)
\item Erfinden (Algorithmen), Gestalten (\glqq Look and Feel\grqq{})
\item Beschreiben (zum Zwecke der Wiederverwendung -- \linebreak als
didaktisches Paradigma)
\item Beschaffen (Kauf, Miete, Marktanalyse, Quelli\-zenz\-er\-werb,
Marktf\"ahigmachen eines Labormusters)
\item Konstruieren (formaler Ansatz, ggf. zusammen mit einem
Korrektheitsbeweis)
\item Verfertigen (Entwerfen, Gestalten, Programmieren, Generieren),
\item Analysieren, Testen, Pr\"ufen, Messen, Bewerten von vorhandener
(in Entwicklung befindlicher, fertiggestellter) Software
\item Fehler Lokalisieren und Beheben
\item Installieren von Software (\glqq Customizing\grqq{},
Distribution)
\item Aktualisieren (\glqq Migration\grqq{}, \glqq Porting\grqq{},
Versions\-fort-\linebreak schrei\-bung, \glqq Patching\grqq{})
\end{itemize}

\noindent Schwerer f\"allt es, sich dar\"uber zu einigen, welches
relative Gewicht diesen T\"atigkeiten zuf\"allt, in welcher zeitlichen
Reihenfolge sie notwendig werden, ob und wie sie ggf. instrumentiert und
arbeitsteilig abgewickelt werden und in welchem Umfange sie in die
Zust\"andigkeit des Software-Ingenieurs fallen.

Seit Garmisch haben sich bekanntlich gewisse
Standard-Vor\-stel\-lun\-gen \"uber den \glqq
Software-Entstehungsproze\ss{}\grqq{}, m\"og\-liche \glqq
Software-Lebenszyklen\grqq{} sowie dazugeh\"orige Methoden und Werkzeuge
herausgebildet. Bei den hier gemeinten Standard-Vorstellungen geht es
nicht so sehr um die Festlegung auf eines der konkurrierenden
Programmier-Para\-dig\-men wie funktionsorientierte Programmierung,
abstrakte Datentypen, logisches oder objektorientiertes Programmieren
oder um Fragen der Programmiermethodik wie sie etwa die IFIP Working
Group 2.3 \"uber viele Jahre untersucht hat, und auch nicht prim\"ar um
Fragen der Programmiersprachen-Syntax oder -Semantik. Es geht vielmehr
um Anspr\"uche, Zust\"andigkeiten und empfohlene Vorgehensweisen der
Soft\-ware-Technologie in einem sehr allgemeinen Sinn, gest\"utzt auf
gewisse Annahmen dar\"uber, was denn wohl in \glqq der Praxis\grqq{}
typisch, normal, der jeweilige Regelfall sei.

Es lohnt sich, zu diskutieren, ob diese Standard-Vor\-stel\-lun\-gen der
heutigen Praxis noch angemessen sind oder ob sie aktualisiert werden
sollten, und wenn, wie. Wesentliche Inhalte einer solchen Diskussion
werden auch im Beitrag von C.~Floyd in diesem Heft angesprochen. Wir
stellen hier zun\"achst einige Grundgedanken der
Standard-Vor\-stel\-lun\-gen zusammen.


\vspace{-7pt}
\section*{Traditionelle Ausrichtung des  Software-Engineering}

Zahlreiche Software-Engineering-Metho\-do\-lo\-gen (nat\"urlich z\"ahlen
wir G. Goos und A. Endres nicht zu ihnen, vgl. den A. Endres gewidmeten
Beitrag von G. Goos in diesem Heft) stimmten, wie wir glauben, in der
Vergangenheit weitgehend in den folgenden Punkten \"uberein:

\smallskip
\noindent{\it Anwendungsferne.} Software-Engineering hat prim\"ar {\it
nicht den Gebrauch von Software zum Gegenstand}, es sei denn im Kontext
der Anwendung von Software-Werkzeugen.

\smallskip
\noindent{\it Gestaltung kein Haupthema.} Software-En\-gi\-neer\-ing
versteht sich {\it nicht} als eine Disziplin des {\it
anwendungsorientierten} Designs. (Gemeint ist der Unterschied zwischen
dem \glqq Domain(s) Analyst\grqq{}, dessen Rolle durchaus
Software-Engineer\-ing zu subsumieren beansprucht, und dem \glqq Domain
Expert\grqq{}, der in seiner eigenen Welt zu Hause ist, in die der
Software-Ingenieur nicht eindringen will. Vgl. hierzu [1].)

\smallskip
\noindent{\it Werbung kein Thema.} Software-Engineering befa\ss{}t sich
auch nicht mit der Frage, wie denn einmal vorhandene Software \glqq{\it
an den Mann}\grqq{} (oder \glqq an die Frau\grqq{}) {\it gebracht
werden} k\"onnte. Das ist Aufgabe der Kaufleute.

\medskip
\noindent{\it Auftragsentwicklung.} Software-Engineering unterstellt ein
\glqq {\it Bed\"urfnis nach Software}\grqq{} und handelt von den Wegen
zur Befriedigung dieses Bed\"urfnisses. Es wird angenommen, da\ss{} die
{\it Nachfrage nach Software zeitlich vor dem Angebot} kommt, d.h.
da\ss{} im Regelfall Software nach Vorgabe einer
Anforderungsspezifikation \glqq nach Ma\ss{} gefertigt\grqq{} und nicht
\glqq von der Stange\grqq{} (engl. \glqq off the shelf\grqq{} ) aus
schon Vorhandenem ausgew\"ahlt, beschafft und ggf. noch \glqq
konfektioniert\grqq{} (\glqq customized\grqq{}) wird.

\medskip
\noindent{\it Vorgehensmusterzwang.} Es wird angenommen, da\ss{} die
genannten T\"atigkeiten schwerpunktm\"a\ss{}ig an ganz bestimmten
Punkten eines \glqq Software-Entwicklungsprozesses\grqq{} stattzufinden
und jeweils zu ganz bestimmten Ausformungen von Zwischenergebnissen und
Teilresultaten zu f\"uhren haben. Im Extremfall wird sogar angenomen,
da\ss{} es {\it nur} einen \glqq {\it besten Weg}\grqq{} zum Ziel gibt.
(Diese Vorstellung ist mit dem Taylorismus verwandt.) Erst in j\"ungster
Zeit wurde gezeigt, da\ss{} bei Wahl geeigneter \glqq Metamodelle\grqq{}
auch sehr verschiedene Vorgehensweisen mit verschiedenen
Vorgehensmustern zu vergleichbaren Ergebnissen f\"uhren k\"onnen [2].

\medskip
\noindent{\it Regelfall Neuentwicklung.} Es wird angenommen, da\ss{} die
Neuentwicklung von Software \glqq auf der gr\"unen Wiese\grqq{} (\glqq
from scratch\grqq{}) die Regel und die Anlehnung an Vorbilder in Design
und Realisierung die Ausnahme ist.\footnote{ Sogenannte \glqq
Wiederverwendung\grqq{}(engl. \glqq reuse\grqq{} ) von Software ist ein
erkl\"artes Ziel, jedoch bis vor kurzem kaum g\"angige Praxis.} (Dies
bewirkt dann, da\ss{} Software- Entwicklungsprojekte mit gro\ss{}em
Arbeitsaufwand als typisch angesehen werden und damit wiederum
Arbeitsteiligkeit auf der Entwicklerseite als Regelfall vorzusehen ist.
Hieraus ergibt sich dann ferner der Unikats- bzw. Rarit\"ats-Charakter
der neu geschaffenen L\"osung mit seinen wohlbekannten
charakteristischen M\"angeln.)

\medskip
\noindent{\it Methodische Qualit\"atssicherung.} Es wird angenommen,
da\ss{} Produktzuverl\"assigkeit als Begriff wohldefiniert ist, immer
die h\"ochste Priorit\"at hat und ausschlie\ss{}lich durch Einsatz
besonderer qualit\"atssichernder (ggf. formal unterst\"utzter)
Ent\-wurfs-, Realisierungs- und Test-Verfahren und/oder durch Messen und
Bewerten (Software-Metriken) erreichbar ist (im Gegensatz zu den
M\"og\-lich\-kei\-ten des Qualit\"atszuwachses \"uber ein hohes Ma\ss{}
von Probatheit, d.h. dadurch, da\ss{} mit Erfahrungsr\"uckf\"uhrung in
eine Folgeversion bei hoher Auflageziffer der Vorg\"angerversion
Mannjahrtausende von Testzeit qualit\"atsf\"ordernd genutzt werden).

\medskip
\noindent{\it Freiz\"ugigkeit der Meta-Terminologie.} Es wurde
angenommen, da\ss{}, ungeachtet der extrem hohen Genauigkeits- und
Zuverl\"assigkeitsforderungen an die zu erstellende Software, die \glqq
{\it Meta-Terminologie}\grqq{} dem Software-Ingenieur weitgehend
anheimgestellt ist. Es fehlt zwar nicht an Normen, Thesauri und
Glossaren in englischer und deutscher Sprache, diese behandeln jedoch
\"uberwiegend die Sprache der Produkte selbst, nicht die Sprache, in der
\"uber sie gesprochen wird.\footnote{Von einer verantwortungsvollen
Terminologiekontrolle kann wohl speziell bei den derzeitigen
anbieterseitigen \"Ubersetzungen aus dem Englischen beim besten Willen
nicht die Rede sein.} Im vorliegenden Heft wird die Thematik der
Begriffskl\"arung in sehr grundlegender und systematischer Weise
aufgegriffen: im Aufsatz von Hesse et al.

\medskip
\noindent{\it Brandmauer Systemgrenze.} Es wird angenommen, da\ss{} der
Anwender ausschlie\ss{}lich anwendungsseitige und der Systementwickler
ausschlie\ss{}lich systemseitige Gestaltungs\-frei\-r\"aume auf der
Basis von gemeinsam verabschiedeten Spezifikationen ausformen darf und
zu vertreten hat.

\section*{Rolle und Status des Software-Ingenieurs}

Im Hintergrund der vorhergehenden Betrachtungen steht (oft
unausgesprochen, als Position auf einer \glqq hidden agenda\grqq{})
zus\"atzlich die Forderung nach einem Idealbild, einem \glqq
Technikhelden\grqq{}, dem \glqq{\it Software-Ingenieur}\grqq{}. Dieser
sollte, so stellt man sich u.a. vor, \"ahnlich wie ein traditioneller
\glqq Hardware\grqq{}-Ingenieur, z.B. ein Maschinenbauer \"alteren
Stils, der Tabellenb\"uchlein und Rechenschieber stets bei sich f\"uhrt,

\begin{itemize}
\item begreifbare simple Hilfsmittel bereithalten und einsetzen,
\item auf diese gest\"utzt standardm\"a\ss{}ige L\"osungen vorschlagen,
realisieren oder realisieren lassen.
\end{itemize}

\noindent Zu diesem Bild pa\ss{}t auch die Vorstellung, da\ss{} diese
Person vertrauensw\"urdig ist in bezug auf zuverl\"assiges
Projekt-Management, die Einhaltung von Kosten und Terminen und auch die
Realisierung zugesicherter Eigenschaften.

In den Augen der breiten \"Offentlichkeit wurde und wird der Ingenieur
als Verantwortungstr\"ager, {\it Garant von technischer Qualit\"at und
Sicherheit}, deutlich abgesetzt gesehen vom Forscher (Garant der \glqq
Wissenschaftlichkeit\grqq{} ) auf der einen und vom Designer und \glqq
Stylist\grqq{} (Garant der formalen Eleganz, der Gef\"alligkeit und der
Erfindungsh\"ohe) auf der anderen Seite.

Weniger gut scheinen in das Bild vom \glqq Vertrauenstr\"ager
Ingenieur\grqq{} \footnote{Es hei\ss{}t, da\ss{} jahrzehntelang viele
M\"utter von T\"ochtern, vor allem in den Mittelmeerl\"andern, sich
einen Eisenbahningenieur zum Schwiegersohn w\"unschten.} zu passen:

\begin{itemize}
\item Aktivit\"aten auf dem Gebiet des Produktdesigns und des
Produkt-Marketing (das entspr\"ache einem Abgleiten in die Rolle \glqq
Stylist\grqq{}) oder
\item die Verwendung oder Erstellung von \glqq
Public-Domain\grqq{}-Software, experimenteller Einsatz noch
unerprobter\linebreak Werkzeuge und das Erstellen von Wegwerf-Prototypen
(das entspr\"ache der Rolle des \glqq Forschers\grqq{} oder gar des
verteufelten \glqq Hackers\grqq{}, der in der Meinung mancher schon
zwischen Genie, Wahnsinn und Verbrechen anzusiedeln ist).
\end{itemize}

\noindent Ein offenkundiger Konflikt, den dieses extrem konservative
Personenbild des Software-Ingenieurs mit sich bringt, liegt sicher
darin, da\ss{} einerseits Software f\"ur unser Jahrhundert der
dramatischste Innovationstr\"ager \"uberhaupt ist und man andererseits
dem zust\"andigen Ingenieur den Gebrauch der Innovationsorgane {\it
Erfindung} und {\it Gestaltung} verbietet, verleidet oder anderweitig
erschwert (vgl. hierzu [3]).

Selbst wenn man unterstellt, da\ss{} die genannten Vorstellungen vor 25
Jahren den Kern der Probleme trafen (keine Schande, wenn es nicht so
war), mu\ss{} man doch heute gewisse Ver\"anderungen einfach zur
Kenntnis nehmen.

\section*{Was hat sich seit Garmisch wesentlich ver\"andert?}

\begin{itemize}
\item[1.] Software-Produkte, insbesondere konkurrierende,
funktionsm\"a\ss{}ig vergleichbare (oder Soft\-ware-Komponenten von
Hardware-Produkten) verschiedener Anbieter haben gegen\"uber dem
klassischen {\it Software-Projekt}, d.h. der Software-Einzelanfertigung,
enorm an Bedeutung gewonnen. (Die Auflagenziffern erfolgreicher
Software-Produkte reichen von mehreren 100~000 bis zu mehreren 10
Millionen.)
\item[2.] Der {\it Markterfolg von Software-Pro\-duk\-ten} beruht
z.T.\linebreak nicht nur auf Eigenschaften, die durch Funktionalit\"at
und \linebreak Durchsatz (Performanz) allein charakterisiert werden
\linebreak k\"on\-nen, sondern schlie\ss{}en auch Benutzerakzeptanz und
Anmutung auf Grund \"asthetischer Gestaltungsmerkmale, sowie
R\"ucksichtnahme des Entwicklers auf die Spezifika des
Anwendungsgebietes mit ein. Es hierbei keineswegs darum, da\ss{} ein
technisch brauchbares Produkt nachtr\"aglich (nur) noch mit einer
modischen Oberfl\"ache versehen w\"urde, sondern es geht um
Design-Qualit\"aten, die von Anfang an sowohl mit den aktuellen
technischen und technologische Voraussetzungen wie auch mit den
aktuellen soziotechnischen Gegebenheiten abgestimmt werden m\"ussen.
\item[3.] Software-Produkte wenden sich mehr und mehr an \glqq
unbetreute Anwender", sei es in Form von \"offentlich zu\-g\"ang\-lichen
Benutzungsoberfl\"achen (z.B. OLPC's = \glqq Online Public
Catalogues\grqq{} in \"offentlichen Bibliotheken), sei es in Form von
Textsystemen, Rechenbl\"attern etc. f\"ur den Hausgebrauch.
\item[4.] {\it Software-Projekte} sind vor allem dort erfolgreich, wo
die Anbieter der Software-L\"osung als Branchen-Spezialisten auftreten
und \"ahnlich wie Arzt, Rechtsanwalt oder Steuerberater dadurch einen
Informationsvorsprung besitzen, da\ss{} sie eine Vielzahl von Klienten
mit sehr \"ahnlich gelagerten Problemen betreuen. Software-Projekte, bei
denen der Software-Anbieter keine Branchenerfahrung hat, geraten ohne
intensive Kommunikation mit dem Endanwender sehr oft in Schwierigkeiten.
\item[5.] Bei erfolgreichen Software-Produkten, aber auch bei
innovativen Software-Projekten steht sehr oft eine \glqq{\it
Schule}\grqq{}\linebreak {\it oder eine einzelne Person} im Hintergrund,
der es gelungen ist, durch geeignete Wahl der Mittel bisher f\"ur
schlecht vertr\"aglich gehaltene Anforderungen zu harmonisieren und zu
befriedigen. Dies geschieht nicht selten im Rahmen einer {\it
ganzheitlichen} \glqq{\it Vision}\grqq{}, die aber nicht Vision bleibt,
sondern sehr konkrete Gestalt annimmt. (Als einer der prominentesten
\glqq Vision\"are\grqq{} sei N.Wirth, der Erfinder von PASCAL, genannt,
der in einem Aufsatz dieses Heftes seine Sicht der \glqq Software-
Explosion\grqq{} darstellt.)
\item[6.] Der {\it Einsatz formaler Verfahren}, h\"ochste
Zuverl\"assigkeit garantieren, im Software-Engineering erfordert, wie
wir heute ziemlich sicher zu wissen glauben, einen sehr hohen Aufwand,
der unstrittigerweise immer dort auch gerechtfertigt ist, wo
menschliches Leben, Gesundheit oder hohe Sachwerte auf dem Spiele
stehen, also z.B. im Bereich von Luft- und Raumfahrt und Kerntechnik.

Es gibt aber viele andere Gebiete (Extrembeispiel: Computerspiele), bei
denen ein \"ahnlicher Aufwand wirtschaftlich kaum vertretbar ist.
Gleichwohl gibt es eine Anzahl von Ma\ss{}nahmen im Bereich der
Gestaltung und des Gebrauches von Programmiersprachen, die es erlauben,
viele gef\"ahrliche Fehlerquellen auf einfache Weise zu
verschlie\ss{}en. (Vgl. hierzu die Aufs\"atze von N.Wirth und H.
Klaeren.)
\item[7.] Viele Software-Anwender, und zwar auch die zuvor genannten
\glqq unbetreuten\grqq{}, haben gelernt, im Rahmen einer begrenzten
\glqq Frustrationstoleranz\grqq{} auch mit technisch fehlerhafter
Software oder mit gegen Fehlbedienung unzureichend gesch\"utzter
Software zu leben, sofern es M\"oglichkeiten gibt, bekannten
Fehlerquellen auszuweichen. Oft wird sogar einer \glqq
geradlinigen\grqq{}, aber un\-ge\-sch\"utz\-ten L\"osung der Vorzug vor
einer \glqq idiotensicheren\grqq{} Software gegeben, die sich bei der
Benutzerf\"uhrung allzu penetranter Schulmeisterei beflei\ss{}igt.
\end{itemize}

\vspace{-11pt}
\section*{Schlu\ss{}folgerung: Die Divergenz ist offenkundig}

Es wurde nicht erst im Kontext der aktuellen Wirtschaftskrise beklagt,
da\ss{} der deutsche und allgemeiner der europ\"aische Beitrag zum
weltweiten Softwaremarkt nach Angebotsvielfalt und Verbreitung sehr zu
w\"unschen \"ubrig l\"a\ss{}t, obwohl Bund, L\"ander und die
Europ\"aische Gemeinschaft wiederholt viele Tropfen aus ihren
F\"ullh\"ornern auf die d\"urst\-en\-de Flur gesch\"uttet haben und
obwohl die europ\"aischen Bildungseinrichtungen in dem Ruf stehen,
Ingenieure hoher Qualit\"at zu \glqq produzieren\grqq{}. K\"onnte es
sein, da\ss{} hier auch das Selbstverst\"andnis des traditionellen
Software-Engineering\linebreak eine Rolle gespielt hat?

Garmisch war eine weit \"uberwiegend europ\"aische Veranstaltung, die
ein starkes weltweites Echo gehabt hat. Aber wo sind die Fr\"uchte?
Schie\ss{}en wir vielleicht immer noch mit dem (inexistenten) \glqq
Silver Bullet\grqq{}, der \glqq Freikugel\grqq{} auf eine (vielleicht
inexistente) \glqq Software-Krise\grqq{} (vgl. Beitrag Spillner),
tr\"aumen wir unsere l\"angst obsoleten
Schraubenschl\"ussel-Ingenieurs-Tr\"aume weiter, statt uns ein Beispiel
an den gro\ss{}en US-amerika\-ni\-schen Software-Manufakturen zu nehmen?
Nichts ist so erfolgreich wie der Erfolg.

\vspace{-7pt}
\section*{Wo k\"onnte man ansetzen?}

\vspace{-3pt}\noindent
{\it Beim Wiedererlernen eines verantwortungsvollen Gebrauchs der
technischen Sprache}\footnote{Deutsch oder Englisch} (Wittgenstein,
Tractatus\footnote{Vorwort; als Motto dem ALGOL-60-Bericht \cite{naur}
vorangestellt}: \glqq Was sich \"uberhaupt sagen l\"a\ss{}t, l\"a\ss{}t
sich klar sagen; und wovon man nicht reden kann, dar\"uber mu\ss\ man
schweigen.\grqq ):

\smallskip\noindent
Wiederverwendbarkeit (\glqq Reusability\grqq{}) von fertigen Software-
Komponenten kann nur gew\"ahrleistet werden durch \"Uben eines gewissen
Ma\ss{}es von Terminologie-Disziplin, dessen Minimalschwelle nicht
unterschritten werden darf. Dies gilt sowohl f\"ur die
Anwenderterminologie wie f\"ur die Terminologie der eingesetzten Mittel.

\vspace{-7pt}
\subsection*{Bei der Gestaltung von L\"osungen:}
\vspace{-2pt}
Man sollte hier
\begin{itemize}
\item mehr Gewicht legen auf Visualisierung und Interaktion,
Konvivialit\"at der L\"osungen\par\eject
\item konsequent objektorientierte Methoden als Mittel der funktionellen
(d.h. technischen) und begrifflichen (d.h. sprachlichen) Gliederung
einsetzen
\item das Verst\"andnis f\"ur die Kriterien der \glqq intrinsischen
Motivation\grqq{} f\"ordern, die ein geschickt gestaltetes
Softwareprodukt im Anwender auszul\"osen vermag
\item{die Belastbarkeitsgrenzen der Merkf\"ahigkeit des
Gelegenheitsbenutzers beachten (Ein mittelm\"a\ss{}iges Papier-Manual zu
einer schlecht gestalteten Benutzungsschnittstelle wird nicht besser,
wenn man es mittels \glqq Online-Hilfe\grqq{} durchsuchen kann.)}
\item die heute marktg\"angigen L\"osungen unter den genannten
Gesichtspunkten bewerten.
\end{itemize}
\subsection*{Bei systematischer stilreiner Wiederverwendung von
Konzepten {\rm (Goethe, Faust: \glqq Was du ererbt von deinen V\"atern
hast, erwirb es, um es zu besitzen!\grqq{}\protect):}}
Vom Professionellen, dem Vielbenutzer, der ein System mit Gel\"aufigkeit
anwendet, wird das Kontrahabituelle rasch als kontraintuitiv bewertet.
Die eigentlich Betroffenen bei den ihnen zugemuteten \glqq
Migrationen\grqq{} sicher zu f\"uhren, kann nur in einer geordneten
Begriffs- und Produktwelt gelingen, in der
\begin {itemize}
\item das zuf\"allige Sosein vom wohlbegr\"undeten klar unterschieden
werden kann
\item Problemweltdetails nicht unn\"otig mit L\"osungsdetails
verschr\"ankt werden
\item das \glqq Prinzip der geringsten Verwunderung\grqq{} beachtet wird
und
\newpage
\item allgemeine Modellbegriffe vor der pathologischen Erfindungswut von
Entwicklern und Marketing-Managern gesch\"utzt werden.
\end{itemize}
\noindent (Die super-originelle Erfindung begeistert meist ihre Urheber
weit mehr als die Betroffenen.) Vorsicht mit \glqq vermeintlichen
Wohltaten\grqq{} im Rahmen der Sch\"opfung von Rezepten und Werkzeugen,
die man selbst nicht benutzt und mit der Verfertigung von Repositorien
und Beh\"alterstrukturen, die andere f\"ullen sollen.
\vskip-1mm\vskip0pt
\subsection*{Beim Endanwender:}
\begin{itemize}
\item mehr \glqq Go and Look\grqq{}, weniger \glqq Sit and Think\grqq{}
\item mehr lernen durch \glqq Voir faire\grqq{}, weniger durch \glqq Oui
dire\grqq{}.
\end{itemize}

\begin{thebibliography}{Literatur}

\bibitem{P-D1}
Prieto-D\'iaz, R., Arango, G.: Domain Analysis and Software Systems
Modeling. IEEE Computer Society Press 1991
\bibitem{Ost}
\"Osterle, H., Gutzwiller, T.: Konzepte Angewandter Analyse- und
Design-Methoden. Band 1 und 2. Hallbergmoos: Verlag Angewandte
Informationstechnik 1992
\bibitem{Rop}
Ropohl, G.: Technologische Aufkl\"arung. Beitr\"age zur
Technikphilosophie, Suhrkamp 1991
\bibitem{naur}
Naur, P. (ed.): Revised Report on the Algorithmic Language ALGOL 60.
Numer. Math. {\em 4}, 420-453 (1962)
\end{thebibliography}
\begin{small}
\vskip10.925pt
\noindent Eingegangen 10.1.1994; in \"uberarbeiteter Form
27.1.1994\\[8.025pt] Dr. Jan Witt\newline
Digital-PCS Systemtechnik GmbH\newline
Pf\"alzer-Wald-Stra\ss{}e 36, D-81508 M\"unchen\par
\end{small}
\end{document}