✔ Nato-Konferenz?
- Themenstarter flashray
- Beginndatum
Nunja das ist eigentlich relativ einfach zu beantworten, das Militär hat schon früh (WK2) das potential von Computern erkannt.
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html
Und das Problem bestand damals darin das man Probleme hatte, große und komplexe Softwareprojekte zu realisieren. (Software Krise)
Natürlich auch im militärischen Bereich. Gerade hier musste/muss man eine gewisse Qualität verlangen. Wäre ja recht ungünstig wenn ein Kampfjet den falschen Flieger als Feind auffasst oder das Zielsystem eines Panzers 10 Meter daneben schiesst.
Daher schreibt die Bundeswehr für Softwareprojekte einen speziellen Entwicklungsprozess vor. (Nicht nur die BW, aber die hat damit angefangen,inzwischen wird das von ziemlich allen staatlichen Stellen vorgeschreiben)
MfG Nomad
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html
Und das Problem bestand damals darin das man Probleme hatte, große und komplexe Softwareprojekte zu realisieren. (Software Krise)
Natürlich auch im militärischen Bereich. Gerade hier musste/muss man eine gewisse Qualität verlangen. Wäre ja recht ungünstig wenn ein Kampfjet den falschen Flieger als Feind auffasst oder das Zielsystem eines Panzers 10 Meter daneben schiesst.
Daher schreibt die Bundeswehr für Softwareprojekte einen speziellen Entwicklungsprozess vor. (Nicht nur die BW, aber die hat damit angefangen,inzwischen wird das von ziemlich allen staatlichen Stellen vorgeschreiben)
MfG Nomad
Danke für die Infos!
Mir ist gerade das GPS eingefallen - (gehört zum US-Verteidigungsminitsterium).
Irgendwie ist die Schattenseite der Forschung und Technik und damit auch der Informatik doch schockierend (für mich) - Nutzung für militärische Zwecke.
Wobei mir gerade noch was eingefallen ist, die Nuklearbombe kam zuerst, das Nuklearkraftwerk erst danach.
Vg Erdal
Mir ist gerade das GPS eingefallen - (gehört zum US-Verteidigungsminitsterium).
Irgendwie ist die Schattenseite der Forschung und Technik und damit auch der Informatik doch schockierend (für mich) - Nutzung für militärische Zwecke.
Wobei mir gerade noch was eingefallen ist, die Nuklearbombe kam zuerst, das Nuklearkraftwerk erst danach.
Vg Erdal
takidoso
Erfahrenes Mitglied
Wenn ich mich nicht irre hat man in Deutschland im 2. Weltkrieg tatsächlich nach einer Energiequelle anfangs gesucht, so zumindest die Legende.
Auf Befürchtung Alberts Einsteins, die Deutschen würden bzw könnten die A-Bombe entwickeln und entsprechenden Briefen an die damalige US-Regierung wurden die bekannten Forschungen in Richtung Bombe forciert.
Die Ironie der Geschichte endes der letzten Deutsche U-Boote war mit Nuklearen Material und diversen Konstruktionsplänen für Japan geriet in die Hände Amerikas, somit hatten die Amerikaner genug Material für Ihre Bombe, welches sie vorher nicht hatten.
Heufig wird, nicht selten von Militärs gemeint, Der Vater aller (oder der meisten ) Erfindungen sei der Krieg...
Dazu sage ich nur Not macht halt erfinderisch ;-)
PS sorry dass das Thema nu etwas off-Toppic ist
Takidoso
Hallo Takidoso,
danke für deinen Beitrag.
Als ich in der Software Engineering Vorlesung das erste mal von der NATO-Konferenz hörte, hatte ich mich gewundert.
Wie du aber beispielhaft geschildert hast, sind die Treiber für Technik und Wissenschaft nicht immer Bestrebungen für das Wohl der Menschen, was mir heut etwas mehr klarer geworden ist.
Vg Erdal
danke für deinen Beitrag.
Als ich in der Software Engineering Vorlesung das erste mal von der NATO-Konferenz hörte, hatte ich mich gewundert.
Wie du aber beispielhaft geschildert hast, sind die Treiber für Technik und Wissenschaft nicht immer Bestrebungen für das Wohl der Menschen, was mir heut etwas mehr klarer geworden ist.
Vg Erdal
takidoso
Erfahrenes Mitglied
Also ich habe den Link mal geöffnet und angefangen die damalige Diskusion zu lesen. Die Vorwörter und Einführungen habe ich mal weggelassen.
Ich finde die Diskusion bezüglich akademische oder im Gegensatz zu industrielle (hier als software engeneering bezeichnet) Ansätze, techniken praktiken, sehr interessant. Nicht selten sehe ich mir Code von Kollegen an und es gruselt mir, sei es weil ich mir einbilde alles besser zu machen, oder weil ich mich bemühen muss, mich in die Gedankenwelt jemanden anderes hinein zu versetzten, der einen ganz anderen Stil hat. Dies ist bekanntlich sehr mühevoll, kostet Zeit, Geduld und Nerven. Offenbar waren die damaligen Anwesenden bei dieser Diskusion genau bei diesem Punkt, dass sie sich etwas haben einfallen lassen müssen, um Brücken zu den verschiedenen Programmstilen schlagen zu können.
Ich halte diese Diskusion für nach wie vor sehr aktuell, denn man arbeitet bei größeren Projekten nunmal oft mit anderen zusammen, die vermutlich ganz andere Stile haben. Und sich dessen bewußt zu werden und zu versuchen die daraus entstehenden Probleme zu kompensieren ist zum einen Aufgabe der Projektleitung, aber auch der vorangegangenen Planung, denn habe ich eine Gruppe von Entwicklern, die noch nie miteinander gearbeitet haben, kann sowas tatsächlich zu mächtigen Reibungen und Reibungsverlusten führen. Also sollte auch dies bei einer Terminplanung etc berücksichtigt werden. Ebenso sollte man als entwickelnder Projektmitarbeiter sich ebenfalls dessen bewußt sein, dass nun mal ein und die selbe Aufgebe 100 Informatiekrn gestellt zu konkret 100 verschiedenen Lösungen führt. Und das man vielleicht hin und wieder sich selbst im Zaum halten sollte um seine Ansichten dem anderen nicht zu kühn oder zu unsensibel mitzuteilen. Softwareentwicklung in Projekten mit mehr als einem Entwickler für die gleiche oder ähnliche Thematik ist halt oft mit Kompromissen zu bewerkstelligen. Das ist einerseits ein eine Form der teamfähigkeit, andererseits auch eine Frage des generellen Erfolges (abgesehen davon, dass es technisch auch viel bessere Möglichkeiten gegeben haben mag). Ich muss zugeben, dass ich mich von deratigen menschlicehn Eitelkeiten nicht ausnehmen darf.
in diesem Sinne
Takidoso
Ich finde die Diskusion bezüglich akademische oder im Gegensatz zu industrielle (hier als software engeneering bezeichnet) Ansätze, techniken praktiken, sehr interessant. Nicht selten sehe ich mir Code von Kollegen an und es gruselt mir, sei es weil ich mir einbilde alles besser zu machen, oder weil ich mich bemühen muss, mich in die Gedankenwelt jemanden anderes hinein zu versetzten, der einen ganz anderen Stil hat. Dies ist bekanntlich sehr mühevoll, kostet Zeit, Geduld und Nerven. Offenbar waren die damaligen Anwesenden bei dieser Diskusion genau bei diesem Punkt, dass sie sich etwas haben einfallen lassen müssen, um Brücken zu den verschiedenen Programmstilen schlagen zu können.
Ich halte diese Diskusion für nach wie vor sehr aktuell, denn man arbeitet bei größeren Projekten nunmal oft mit anderen zusammen, die vermutlich ganz andere Stile haben. Und sich dessen bewußt zu werden und zu versuchen die daraus entstehenden Probleme zu kompensieren ist zum einen Aufgabe der Projektleitung, aber auch der vorangegangenen Planung, denn habe ich eine Gruppe von Entwicklern, die noch nie miteinander gearbeitet haben, kann sowas tatsächlich zu mächtigen Reibungen und Reibungsverlusten führen. Also sollte auch dies bei einer Terminplanung etc berücksichtigt werden. Ebenso sollte man als entwickelnder Projektmitarbeiter sich ebenfalls dessen bewußt sein, dass nun mal ein und die selbe Aufgebe 100 Informatiekrn gestellt zu konkret 100 verschiedenen Lösungen führt. Und das man vielleicht hin und wieder sich selbst im Zaum halten sollte um seine Ansichten dem anderen nicht zu kühn oder zu unsensibel mitzuteilen. Softwareentwicklung in Projekten mit mehr als einem Entwickler für die gleiche oder ähnliche Thematik ist halt oft mit Kompromissen zu bewerkstelligen. Das ist einerseits ein eine Form der teamfähigkeit, andererseits auch eine Frage des generellen Erfolges (abgesehen davon, dass es technisch auch viel bessere Möglichkeiten gegeben haben mag). Ich muss zugeben, dass ich mich von deratigen menschlicehn Eitelkeiten nicht ausnehmen darf.
in diesem Sinne
Takidoso
Zuletzt bearbeitet:
