Ist schon etwas her, zeigt aber anschaulich die Auswirkungen der
penetranten Nuzung von bad simple english als Kommonikationssprache im
Umfeld des Projektmanagements:
In einem Desgin-Review, bei dem die potentiellen Fehler und
Bedienprobleme eines Geräts erörtert und Massnahmen besprochen wurden,
kam auch die von mir eingereichte Liste bez. des Softwarefehlverhaltens
zur Sprache. Zwei benannte Fehlerzustände waren:
4.1.5 "... PCI bus performes initialization during setup process,
however data packages are not updated but become obsolete"
4.1.6. " after setup process, user still can change parameters, but must
not (acc. to requirement key xyz)"
Den Punkt 4.1.5 hatte der Leiter der Softwareabteilung, der für die
Umsetzung der requirement changes verantwortlich war, noch einigermassen
kapiert und seinen Programmierer angewiesen, die CPU so zu
programmieren, daß die veralteten Kommandos, die sie sendet, unterdrückt
werden, bis der PCI bus wieder im Lot ist, aber
bei Punkt 4.1.6 verliessen ihn seine Englishkenntnisse und er sah keine
Veranlassung an der Software etwas zu verbesseren, ausser den
requirement key xyz aus dem Lastenheft 1:1 ins Pflichtenheft zu
kopieren.
Ergebnis: Die Software säuft auch nach Auslieferung zum Kunden, bei
jeder simplen Paramteränderung ab.
Wer weis warum?
Ich denke er hat das "must" falsch verstanden...
Nach dem setup process soll der User also nichts mehr ändern können...
er dachte also dass der User das machen muss (must), darum het er den
key xyz Pflichtenheft genommen?
Fast! Wie gesagt ist sein English nicht das Beste! Er hatte die
Anforderung im Lastenheft ".. user must not change parameters ..." so
gelesen, daß der Benutzer nach der Setupphase keine Parameteränderungen
machen muss und geschlussfolgert, daß er dann, wenn der User im
Nachhinein etwas ändert, die neue benutzt und ansonsten die alte, die
sich die CPU dann merken muesse. Damit konnte der Prozessor beliebig
viele (fehlgeschlagene Initialisierungen) neu fahren, wodurch er mit zur
Laufzeit wechselnden Setups (also Mischungen !) fuhr. Das Gerät hat
gestreikt, wenn der User zu einem unpassenden Zeitpunkt eine Taste
gedrückt hat.
Das durfte also nicht sein und war im LH auch so benannt. Ergo habe ich
das nochmals als Fehler aufgeschrieben: "user can do, but must not" ->
"Benutzer kann nach erstem Init immer noch ändern, darf es aber laut
Spec nicht" Auch dies hat er wieder in der falschen Richtung kapiert
und nichts gemacht. Daher ging das Gerät mit der Software so raus. Es
hiess später, meine Beschreibung im Lastenheft und dem Protokoll sei
missverständlich. Mein Einwand, daß ein Punkt in einem Fehlerprotokoll
in jedem Fall ein Fehler ist und es deshalb keinen Sinn mache, daß er
einfach nichts unternimmt, liess er nicht gelten.
Ich bin dafür, daß an der FH Zwickau auch im Studiengang Elektrotechnik,
mehr Augenmerk auf das English gelegt wird. Wahrscheinlich machen die da
aber immer noch Russisch.
Ossis und Englisch, das paßt hinten und vorne nicht zusammen. Wobei die
ostdeutschen Unis vom Niveau her sowieso unter aller Sau sind. Wir
hatten mal einen Ossi aus Dresden da (natürlich nur für kurez Zeit bevor
wir ihn abserviert haben... höhöhö), der konnte nicht einmal ein
Oszilloskop bedienen und hatte angeblich in dresden Elektrotechnik
studiert. Da sieht man mal, was es im Osten für ein Scheisshausniveau
gibt.
Das Unverständliche für mich ist, daß es solche Leute mit
offensichtlichen (und kostenträchtigen!) Lücken doch irgendwie in eine
Führungsposition geschafft haben.
schon ne seltsame Regel.
wenn man das Ersatzverb für must verwendet (have to) bedeutet "you don't
have to"= du musst nicht. Wenn man aber must verwendet bedeutet der Satz
du darfst nicht. Da fehlt eben en bisschen die Logik.
Die Engländer invertieren eben öfters nicht die äussere, sondern die
innere Logik! Damit wird nicht die Aussage negiert, sondern das innere
Objekt:
Das Gegenteil von "Mensch ist im Haus" ist im Deutschen eben "Nicht
(Mensch im Haus)" also "Mensch ist nicht im Haus". Im Englischen ist
es aber "Mensch ist Nicht(im Haus)" also er ist im Gegenteil von Haus,
also ausserhalb. Das kann, muss aber nicht dasselbe sein.
Um es bildlich zu zeigen gibt es zwei Extreme und eine oder mehrere
Zwsischenpositionen:
1. Absolut Müssen, 2. Sollen, 3. Ist egal, 4. Eher nicht, 5. Absolut
nicht.
Der Deutsche rechnet alle Fälle von 2-5 als Inversion der 1, also alles,
was nicht der Extremfall links ist. Der Engländer rechnet als Inversion
wieder nur einen Extremfall, dann aber eben den rechten, gegenteiligen.
Das ist nicht vollständig unlogisch, das Deutsche entspricht nur eben
der mathematischen Logik! Besonders kritisch ist es,bei scheinbar
abgeschwächten Inversionen:
"I am not amused" interpretieren viele Deutsche als "nicht gerade
amüsiert" also "er ist nicht so übermäßig angetan von etwas", was man
als nicht so schlimm auslegt. Theoretisch impliziert das zwar auch den
extremen Gegenfall, aber es wird hierzulande nicht so gedeutet. Real
sagt der Engländer aber "I am not(amused)" also des krasse Gegenteil von
amüsiert und das ist nichts anders als "komplett sauer!" Das sollte man
schon wissen.
In anderen Sprachen ist auch die Verwendung einer völligen inhaltlichen
Logikinversion gebräuchlich: Der Radsportkommentator Karsten Migels
kommt nicht selten mit Aussagen wie "der Fahrer war nicht ganz schlecht
unterwegs" womit er nicht sagen will, daß der Fahrer mittelmäßig sondern
extrem gut war.
Aber auch völlige formelle Logikinversionen sind möglich: Die Tschechen
verwenden ganz gerne die Nicht-Nicht Bezeichung, um etwas besonders
hervorzuheben: "Nicht dieses Forum ist nicht gut" heisst nicht, daß eine
anders Forum nicht so toll sei, sondern, daß eben dieses hier besonders
gut ist!
Zugegeben, das wirkt z.T. etwas missverständlich. Das ist es aber nur,
wenn man alles aus deutscher Warte sieht. Wenn man es so sieht, wie der
Originalverwender, dann stimmt alles! :-) Man muss sich eben bewusst
machen, was man tut, wenn man in fremden Sprachen kommuniziert. Da
gehört mehr dazu, als nur die Vokabeln und die Grammatik.
@ "sb" : Dein Beispiel stimmt nicht ganz: Die Inversion von "you have
to" wäre "not (you have to)". Dein "you not(have to)" ist wieder die
deutsche Sichtweise, die nicht notwendigerweise stimmt.
Formell könnte man es auch inhaltich invertieren, wie es z.B: im
Deutschen passiert: "Du hast das nicht zu machen", bedeutet nämlich auch
"darf nicht".
Die ganze Geschichte hat viel mit logischen Sprachstrukturen zu tun und
es gibt nicht wenige Wissenschaftler, die den Deutschen deshalb gutes
und sauberes Denken und Forschen zuschreiben, WEIL sie so eine logisch
anspruchsvolle und strukturierende Sprache haben: Kinder, die das über
die Jahre kapiert haben, entwicklen nachweislich komplexere
Denkstrukturen. Da sind wir aber wieder bei dem anderen Thema, was ein
Abi wert ist und wozu Deutschunterricht nötig ist, bzw. warum es oft
nicht reicht, einfach ein Fachabi oder mittlere Réife zu machen und dann
ein Schmalspurstudieum nachzuschalten.
Ach ja: Die korrekte Inversion der Themenüberschrift wäre im Übrigen
auch: We do not need to do ANYTHING!
"...Ossis und Englisch, das paßt hinten und vorne nicht zusammen. Wobei
die
ostdeutschen Unis vom Niveau her sowieso unter aller Sau sind. Wir
hatten mal einen Ossi aus Dresden da (natürlich nur für kurez Zeit bevor
wir ihn abserviert haben... höhöhö), der konnte nicht einmal ein
Oszilloskop bedienen und hatte angeblich in dresden Elektrotechnik
studiert. Da sieht man mal, was es im Osten für ein Scheisshausniveau
gibt..."
Na, immerhin noch nen höheres Niveau als es der liebe Blaubär hat, der
sieht nichtmal die Stammtischkante, wenn er steil nach oben schaut...
Wenn wir hier schon die sprachlichen Defizite auflisten:
>>Kommonikationssprache
Kommunikationssprache
>>English
Heißt innerhalb eines deutschen Satzes immer noch Englisch.
>>Massnahmen
auch nach neuer deutscher Rechtschreibung immer noch Maßnahmen. Nach
langem Vokal oder Diphtong "ß"
Hast ja Recht, Dennis- aber: An Forenbeiträge darf man weniger scharfe
Kriterien anlegen, als an Revisionsberichte und Tippfehler sind sicher
zwei Nummern ungefährlicher, als totale Fehlintrepretationen.
Mihin ging es mir nebst den mangelnden Englischkenntnissen besagter
Person (die aufgrund seiner Position eher besonders gut, statt besonders
schlecht sein sollten) auch darum, das Vorgehen in vielen Firmen
"anekdotisch" anzuprangeren, immer mit aller Gewalt alles in Englisch
abwickeln zu wollen.
Nur sollte man nicht andere für seine eigenen Fehler verantwortlich
machen
(zumindest wenn die Defizite bekannt sind).
Warum statt "after setup process, user still can change parameters, but
must
not (acc. to requirement key xyz)" nicht einfach
"after setup no (further) changes allowed"?
>> "after setup no (further) changes allowed"?
Na so kanns ja jeder g, außerdem klingt es nicht so geschwollen und
braucht weniger Platz in Lastenheft. Und wer mag schon ein dünnes, klar
verständliches Lastenheft?
"after setup no (further) changes allowed"
Ganz Einfach. Weil es eine andere Aussage ist.
Im Originaltext ist der Fehler klar beschrieben und auch gesagt, wie das
richtige Verhalten sein soll. Das ist an Klarheit kaum zu überbieten.
Wenn man schreibt "No changes allowed" sagt das nichts darüber aus, was
der derzeitige Zustand ist.
Ich sehe auch nicht, wie verquer man denken soll, um aus "can change
parameters" und "must not" in einem Fehlerprotokoll etwas anderes
ableiten soll als "sorge dafür, dass das nicht mehr geht". An dem "must
not" gibt es irgendwie nichts zu drehen. Er kann es jetzt und er darf es
nicht.
"immer mit aller Gewalt alles in Englisch abwickeln zu wollen."
Damit ist man auf der sicheren Seite. Hatten mal den Fall, dass wir eine
Studie für eine deutsche Firma ausgearbeitet hatten, die einem deutchen
Endkunden vorgestellt werden sollte. Am Abend vor der Präsentation
stellt sich heraus, dass der Marketingchef der amerikanischen
Muttergesellschaft kurzfristig auch dabei sein möchte und die
Präsentation am liebsten selbst halten würde. Der sah natürlich aus wie
ein Idiot.
Dumm gelaufen. Hat uns ein paar Aufträge gekostet.
Gruss
Axel
Zusätzlich zu dem, was Axel sagt und als Antwort auf "yzc": Ein
Fehlerprotokoll dient nicht dazu, dem Umsetzer seine Aufgaben nochmal zu
erklären, sondern konkrete Fehler zu bennen und die Nennung lautete
eben: "Es passiert was, der User kann es beeinflussen, darf es aber
nicht". Wer das nicht kapiert, muss sich eben die Anforderungen im Ph
nochmal genau ansehen oder rückfragen. Selbst wenn diese Vorgabe nicht
schon im Vorhinein vorhanden gewesen wäre, beschreibt meine
Fehlerdarstellung ein Problem, das aus den Tests hervorgegangen ist. Es
besteht also ein Handlungsbedarf. Und dies besonders, da es in einer
Fehlerliste steht. Das ist für mich einfach nur Logik.
Sicher, ich sehe die Angelegenheit generell auch so, daß man alles klar
erklären sollte, aber das hatte ich ja getan. Woher soll man wissen,
wann einer etwas nicht verstehen wird? Klar könnte man alles doppelt und
dreifach erklären, aber wie weit soll man gehen? Welche Kompetenz darf
man beim Gegenüber vermuten?
Aus dem, was hier (auch von Blaubär) gesagt wurde, muss ich natürlich
mitnehmen, daß man es manchen Leuten so deutlich erklären muss, wie man
es Verona Feldbusch erklären würde. Da landen wir aber schnell bei der
Frage nach der Arbeitseffizienz. Wenn ich mir den Laden mit
Halbkompetenten volllade, komme ich eben nicht voran. Oder aber man läßt
die englische Sprache beiseite, wenn es die eigenen Leute nicht
draufhaben.
> Wenn ich mir den Laden mit
Halbkompetenten volllade, komme ich eben nicht voran
Das ist mir auch schon aufgefallen, aber so Schimpansen sind billiger!!!
Ach Leudde - es gibt hier in der Firma wo ich arbeite so viele Ing.s die
kein / kaum Englisch können (fast alle Wessis) -> und so viele
ausländischen Arbeiter sowie Zulieferer dazu...und die hatten bei weitem
länger Zeit Englisch zu lernen - und was können sie ?
Das hat absolut nix mit der Herkunft zu tun - ich behaupte sogar: fast
nur mit der eigenen Veranlagung...
Und - natürlich ist es tragisch das solche Leute auf gehobenere
Positionen kommen - aber warum seit ihr es denn dann nicht ?
---> Frei zum Abschuß <---
nichts genaues weiß man nicht...
Auch im Deutschen wird die doppelte Verneinung unterschiedlich
gebraucht, als Verstärkung der Aussage oder zur Invertierung, das hägt
auch vom Dialekt ab
Solche Unterschiede zu eioner Fremdsprache muß man einfach kennen, auch
z.B. der Unterschied zwischen unserer Billion und der englischen, die
unserer Milliarde entspricht
"Auch im Deutschen wird die doppelte Verneinung unterschiedlich
gebraucht, als Verstärkung der Aussage oder zur Invertierung, das hägt
auch vom Dialekt ab"
Nur, dass hier keine doppelte Verneinung benutzt wurde.
Das steht "must not".
Einfache Verneinung.
Gut, man hätte schreiben können "must not be allowed to" oder "but
software should not let him do so".
Wobei dann wieder einige "should" mit "sollte" im Sinne von "wäre schön,
wenn sie das nicht erlauben würde, ist aber nicht unbedingt notwendig"
übersetzten würden.
Dabei ist "must not" eigentlich schon so krass und extrem unhöflich,
dass einem englischen Leser spontan die Assoziation "deutscher
Militärton" einfallen würde.
Gruss
Axel
Mit der doppelten Verneinung meinte ich das Beispiel aus dem
Tschechischen, oder auch mein Zitat "nichts genaues weiß man nicht", das
dem englischen Professor "Jamie" der während des Balkankriegs als
Natosprecher auftrat, im Deutschen aufgefallen ist.
Mit den deutschen Gegensatzpaaren "müssen/nicht dürfen" und
"dürfen/nicht müssen" oder auch "können/nicht können" wird umgekehrt
auch ein Ausländer Probleme haben
"Cheffe" sollte aber auch mal an seinem Englisch arbeiten. Ein
Muttersprachler haette "must not be allowed to" geschrieben, "must not"
ist missverstaendlich und kann als eine Auflage an den Nutzer
missverstanden werden. Beispiel 1 klingt so wie es da steht ebenfalls
etwas holprig.
Wie stehts mit "may not" ? In einer englischsprachigen x-ten Kopie eines
Handbuchs stand "...may not be copied..." und mitkopiert handschriftlich
darunter "may not, but will!"
"must not be allowed to" ist logisch, denn das würde heissen, daß es ihm
verboten sein sollte. Richtig wäre aber, daß es ihm verunmöglicht werden
soll. Daher müsste es wenn schon heissen "must not be able to do".
Trotzdem halte ich "must not" für vollkommen ausreichend. In den
deutschen Zügen steht ja an den Wagontüren auch immer "must not" fürs
Rauslehenen.
Wenn es einer flasch versteht und glaubt, er müsse nicht, dürfe aber -
wird die Evolution ihn aussortieren!
Sorry. Ich finde das Englisch auch etwas geschwollen. Das geht sicher
einfacher und verständlicher.
Nichtsdestotrotz hätte der Leiter der Software mal nachfragen müssen...
Und deshalb hat der liebe Gott die deutsche Sprache erfunden.
Es gibt kaum eine andere die aussagekräftiger ist als diese.
Die Dichter sind wir net weil wir besonders helle sind sondern weil sich
mit unserer Sprache sehr viel und genau ausdrücken läßt.
Gott zum Gruß
Im letzen Teil des letzen Satzes fehlt noch etwas, damit man weis, was
DU ausdrücken möchtest :-)
Z.B. "weil ... sich viel- und dieses wiederum genau ausdrücken läßt"
Was bringt es denn, wenn da ein Fehlerhinweis in einem denglischen
Projektumfeld eingestellt wird, und kein Mensch rafft den süffisanten
Hinweis oder die spitzfindige Grammatik? B-Note "sehr gut", aber
A-Note "sehr schlecht".
Anders gesagt: Dein Fehler wurde möglicherweise in perfektestem
Oxford-Englisch eingestellt, und du bist damit Anwärter auf den
Pulitzer-Preis, aber keiner hat deine Ergüsse verstanden. Lass dich
fragen: Hast du damit dein mit deinen Aufgaben verbundenes Ziel
erreicht????
Buchstabenwechsler, du liegst im Grunde richtig: Läuft was falsch, muss
sich jeder fragen, was er besswr hätte machen können und für die Zukunft
lernen!
"in perfektestem Oxford-Englisch":
Nun ja, der Aufhänger des Fehlers, nämlich die englische Verwendung von
"must and needn't" hat nichts mit überkandidelten Redewendungen zu tun,
sondern ist Alltagssprache. Aufgaben dazu befinden sich weltweit in
jedem Englischbuch der Klasse 5! Die Grundlgen der Sprachelemente sollte
man schon beherrschen, finde ich, wenn man sich in einem anspruchsvollen
Projektumfeld bewegt.
Das sagt LEO zu der Übersetzung "must not"
It must not happen again! Das darf nicht wieder vorkommen!
The matter must not rest there. Man kann die Sache so nicht belassen.
I must not. Ich darf nicht.
must not be delayed darf nicht verzögert werden
We must not forget ... Wir dürfen nicht vergessen ...
das "must not" bedeutet halt "Du Bösewicht, du darfst das nicht". Das
heißt aber nicht, daß es nicht möglich wäre, eine derartige Aktion zu
machen. ("Du darfst nicht auf die heiße Herdplatte fassen")
Inkorrekt bzw. mit keiner klaren Aktionsaufforderung an die
Entwicklung ist "after setup process, user still can change parameters,
but must not".
--> Also nicht nur das derzeitige Systemverhalten beschreiben ("Nach
Initialisierung kann der Benutzer Eingaben machen, darf des aber
nicht"), sondern einen korrekte Hinweis (bzw. Aufforderung an de
Entwicklung) wäre gewesen, zu fordern, daß an der besagten Stelle
überhaupt keine Eingabe gemacht werden KANN, und welche Auswirklungen es
hat, wenn das bemängelte Verhalten nicht korrigiert wird. ("Dem Benutzer
darf es nicht möglich sein, nach Initialisierung irgendwelche
Laufzeitparameter zu verändern. Ansonsten werden Dateninkonsistenzen und
Programm-Abbrüche auftreten."
Dem Programmierer sind im Zweifelsfalle die fachlichen Zusammenhänge
nicht immer bekannt oder bewußt.
Eine organisatorische Regelung ("Bitte nach Initialisierung keine
Eingaben mehr machen") an so einer kritischen Stelle wird eh wieder
vergessen bzw.. nicht berücksichtigt.
Natürliche Sprache wie Englisch ist missverständlich, deshalb gibt es
für das Schreiben von Spezifikationen Regeln wie die Sprache anzuwenden
ist, über die man Doktorarbeiten schreiben kann, die man sich im
Wesentlichen mit ein wenig Nachdenken aber auch selbst erschließen kann,
sofern man das Problem erkannt hat. Eine davon ist: kein Passiv
verwenden; eine andere ist: genau sagen, WER WAS zu tun/nicht zu tun
hat. Statt "the user must not" oder "the user must not be able to" würde
das also z.B. heißen: "the PROGRAM must PREVENT the user from". Dann
sind Missverständnisse ausgeschlossen.
"--> Also nicht nur das derzeitige Systemverhalten beschreiben ("Nach
Initialisierung kann der Benutzer Eingaben machen, darf des aber
nicht"), sondern einen korrekte Hinweis (bzw. Aufforderung an de
Entwicklung) wäre gewesen, zu fordern, daß an der besagten Stelle
überhaupt keine Eingabe gemacht werden KANN, und welche Auswirklungen es
hat, wenn das bemängelte Verhalten nicht korrigiert wird."
Das war ja beschrieben. Nur wurde es trotzdem falsch gemacht. Im
späteren Fehlerprotokoll wird man nicht nochmal alles wiederholen,
sondern gezielt das herausstreichen, was noch nicht realisiert ist oder
anderweitig falsch läuft. Dort steht auch drin, "Klappe springt auf, bei
Erschütterung, sollte es aber nicht". Was da zu tun ist, ist für
jedermann eindeutig.
Aber manche brauchen es echt doppelt und dreifach redundant.
>Aber manche brauchen es echt doppelt und dreifach redundant.
Im Flugzeug- und Panzerbau ist das grundsätzlich so...
Ist wirklich schade, dass jemand nicht (nach-)fragt, wenn er etwas nicht
verstanden hat, bloß weil er sein Gesicht nicht verlieren will...
Hallo,
die Verwendung von "must" outet massiv als Kenner der englischen
Sprache..
bzgl Absturz etc. Es ist eben die Kunst einerseits "Experte" zu sein,
andererseits DAU mäßig sich schwachsinnigste Eingaben auszudenken.
Auf die Tour konnten an einem vermeintlich fertigem IT-Projekt fast
100 Fehler aufgedeckt werden und hiervon 15 schwerwiegende ( alleine
nur von mir... )
Das ist weit wichtiger als Mehrfachredundanz zu implementieren. Oft ist
diese "Redundanz" keine wirkliche Redundanz .
Hier sei nur anden Flug 232 erinnert, bei welchem alle 4
Hydraulikleitungen
zerschossen wurden von dem wegfliegenden Turbinenrad ( welches einen
Materailfehler hatte )
Da gerade bei Flugzeugen.. Ein Zitat eines Technikleiter bei der LH :
"Würden alle Richtlinien sauber eingehalten, dann müßten 90% aller
LH-Flieger sofort gegroundet werden....
Ich denke das sagt alles .
Irgendeiner hat mir gerade vor Tagen erklärt, daß es ganz normal sei,
daß in Flugzeugen Softwarefehler bestünden und toleriert würden, weil
dort angeblich Softwareupdates nicht erlaubt seien. (ist das so ?) Daher
existiere ein Handbuch, was die Piloten so alles nicht machen dürfen,
weil die Software damit nicht klar kommt. In einem Fall eines Airbus
muss derr Autopilot nach einer wesentlichen Höhenabsenkung resettet
werden, da ers sonst das FLugzeug durchsacken lässt.
Hallo,
ein Flugzeug ist wie alles andere eine menschliche Konstruktion - also
mit versteckten Fehlern behaftet.
Mal schnell einen Software -Update zu machen ist wegen der
Gesamtkomplexität
und der Tatsache, das auf die Tour der ganze Flieger sich schnell in der
zweidimensionalen Ebene wiederfindet natürlich zu vergessen.
Die administrative Fähigkeit der Piloten ist handbuchbeschränkt...
Somit ist die Fehlervermeidung durch prophylaktische Eingabevermeidung
usus
Generell werden die Piloten stark überschätzt. Das sind in summa
überteuert bezahlte Busfahrer . ....
Bzgl Autopilot, solche Fehler sind bedauerlich, zeigen aber auf , daß
bei
entsprechenden Firmen Leute wie ich zB ne Absage bekommen anstatt diese
einzustellen. Das Denken über ein Einzelsystem hinaus bzw was ein
Flugzeug
effektiv denn so macht , ist bei vielen gar L+R Ing nicht vorhanden.
Von einem Programierer erwarte ich das nicht - dafür ist man ja ein
TEAM;
eigentlich....
Der Fall Straßburg übrigens ( also der "Weiterflug" in den Wald )
hätte so sich nie ereignen dürfen . Hier wurden die Hauptsicherungen
manuell deaktiviert. Was der Pilot nicht wußte, war die Tatsache daß
hiermit
das Hochfahren der Triebwerke einen höheren delay hatte --- und
tschüß...
