\documentstyle[twocolumn,german]{article}
\input{trendsstyle.tex}

\begin{document}
\thispagestyle{empty}
\baselineskip12pt


\twocolumn[{
\huge\sf Standpunkte
\\[10mm]
}]

\noindent
{\large \sf Was n"utzen der Software-Technik die
DIN-Normen?}
\\~
\\Ich glaube, wir sind uns alle dar"uber einig, da"s ein
gewisser Grad an Standardisierung in der Software-Technik
n"otig ist. Standards erleichtern die Kommunikation,
reduzieren die Ausbildungskosten, vereinfachen die
Zusammenarbeit, f"ordern die Innovation.

Betrachtet man die DIN-Normen zur Software-Technik, dann
fallen mir zun"achst viele alte Normen ein: Normen zu
Entscheidungstabellen, zu Programm"-ablaufpl"anen, zu
Datenflu"sdiagrammen. Diese Normen waren zum Zeitpunkt
ihrer Ver"offentlichung wegweisend und pr"agen z.T. noch
heute die Software-Technik. Diese Dynamik ist heute leider
nicht mehr vorhanden. Vielmehr haben sich die DIN-Gremien
lange Zeit im wesentlichen damit befa"st, alte Normen zu
modernisieren, obwohl eine Modernisierung nicht sinnvoll
war. Beispielsweise hat man in mehreren Schritten
versucht, die Programmablaufpl"ane, die gut f"ur die
Dokumentation von Assemblerprogrammen geeignet waren, f"ur
die Strukturierte Programmierung anzupassen. Besser w"are
es gewesen, Struktogramme bzw. Nassi/Shneiderman-Diagramme
zu normieren.

"Ahnlich wie bei den Programmablaufpl"anen ist es auch den
Datenflu"sdiagrammen ergangen.

Normierungen auf dem Gebiet der Systemanalyse, das heute
einen Schwerpunkt jeder Software-Technik darstellt, hat es
bis heute meines Wissens nicht gegeben. Es wurde vers"aumt,
die Strukturierte Analyse und das
Entity-Relationship-Modell zu standardisieren. Das hat aus
meiner Sicht mit dazu beigetragen, da"s die deutschen
CASE-Hersteller ``Boden verloren haben''. In Frankreich
wurde mit Merise und in Gro"sbritannien mit SSADM ein
entsprechender Standard gesetzt. Deutsche CASE-Hersteller
haben diese Standards fr"uhzeitig unterst"utzt, da in
diesen L"andern die Software-Industrie diese Standards
benutzte. Mit seiner Nichtt"atigkeit hat der DIN dem
Software-Standort Deutschland keinen Gefallen getan,
sondern ihm geschadet!

Eine fr"uhzeitige Normung in diesem Bereich h"atte nicht
nur den CASE-Herstellern einen Wettbewerbsvorteil
verschafft. Viel wichtiger w"aren noch die Vorteile durch
die erleichterte Zusammenarbeit zwischen Software-H"ausern
gewesen, z.B. durch leichteren Austausch von
Halbfertigprodukten.

Auch heute werden die Zeichen der Zeit offensichtlich
nicht erkannt. Es w"are h"ochste Zeit, eine Norm f"ur die
Objektorientierte Analyse und den Objektorientierten
Entwurf zu verabschieden. In einer innovativen Branche
geh"ort zur Normung Weitsicht, Mut und Risikobereitschaft.
Wenn man immer darauf wartet, bis eine Entwicklung
konsolidiert ist, dann wird man immer die Vergangenheit
normen.

Eine positive Ausnahme gibt es zu vermelden. Mit DIN
66234, Teil 8 ``Grunds"atze ergonomischer
Dialoggestaltung'' wurde Neuland betreten. Und man ist
dabei, diese Norm zu einer internationalen Norm zu
etablieren.

Das heute in aller Munde befindliche Normenwerk ISO
9000ff. wurde von einer britischen Norm "ubernommen.
Dagegen ist nichts einzuwenden. Gerade als Hochschullehrer
finde ich es aber "au"serst "argerlich, wie dieses
Normenwerk "ubersetzt wurde. Englische Begriffe, f"ur die
neue deutsche Begriffe sinnvoll gewesen w"aren, blieben
Englisch, z.B. Audit. Im deutschen "ubliche englische
Begriffe wie Management wurden v"ollig unsinnig
"ubersetzt: Statt Mangement spricht man von ``oberster
Leitung''. Sinnvoll w"are Gesch"aftsf"uhrung gewesen. Diese
sprachliche Mi"sbildung ``oberste Leitung'' findet man
inzwischen in allen Artikeln zu dieser Norm. Fehlt nur
noch, da"s der Duden diesen Unsinn irgendwann legalisiert.
Noch einige Beispiele f"ur die "klare" Formulierung in ISO
9000-3: ``Die oberste Leitung des Lieferanten mu"s ihre
Politik sowie ihre Zielsetzungen und ihre Verpflichtung
zur Qualit"at festlegen und dokumentieren. ... Zus"atzlich
sollten diese Forderungen alle Aspekte enthalten, die
n"otig sind, um den Bedarf des Auftraggebers zu
befriedigen. ... Das Qualit"atssicherungssystem sollte ein
in den gesamten Lebenszyklus integrierter Proze"s sein, um
sicherzustellen, da"s im Verlauf der Entwicklung st"andig
(befriedigende) Qualit"at erzeugt wird,..'' Ich wu"ste noch
gar nicht, da"s ein System ein Proze"s ist!

Au"serdem wurde in dieser Norm mit einem geheiligten
Prinzip gebrochen: Aus meiner Sicht wurde ohne Not der
bisher eingeb"urgerte Begriff {\em Qualit"atssicherung}
durch {em Qualit"atsmanagement} ersetzt. 

Wie lautet das Resumee: Nichthandeln schadet der deutschen
Software-Industrie. In den letzten Jahren wurde nicht
gehandelt. Ich w"unsche mir: Voraussicht und Mut! Und
einen Germanisten!

~\\~
\\Helmut Balzert\\
Lehrstuhl f"ur Software-Technik\\
Ruhr-Universit"at Bochum 

\end{document}
