Softwareentwicklung und ihre Unterstützung für Betrieb und Simulation
Dauer:
Aufnahme:
Andreas Schreiber Institut Simulations- und Softwaretechnik, DLR |
DLR-Softwaretechniker Andreas Schreiber beschreibt im Gespräch mit Tim Pritlove die Aufgaben und Tätigkeiten des DLR-Instituts für Simulations- und Softwaretechnik.
Themen: Aufgaben des Instituts für Simulations- und Softwaretechnik; Anforderungsanalyse; Bug Tracker; Testgetriebene Entwicklung; Programmiersprachenvielfalt; Versionskontrolle; Datenmanagement; die Bedeutung von Open Source für die Forschung; Integrierte Entwicklungsumgebungen; Telemedizin; Open Source Entwicklung; Freie Lizenzen; Technologiemarketing; Ausbildung.
Links:
- DLR: Andreas Schreiber
- DLR: Institut Simulations- und Softwaretechnik
- DLR: Abteilung Verteilte Systeme und Komponentensoftware
- WP: Softwaretechnik
- WP: Anforderungserhebung
- WP: Bugtracker
- WP: Fortran
- WP: C
- WP: Python
- WP: Testgetriebene Entwicklung
- WP: Modultest (Unit Test)
- WP: Java
- WP: C++
- WP: C#
- WP: MATLAB
- WP: Perl
- WP: Tcl
- WP: Concurrent Versions System (CVS)
- WP: Apache Subversion
- WP: Mercurial
- WP: Intranet
- RZ006 Erdbeobachtung
- WP: Eclipse
- WP OSGi
- WP: Telemedizin
- WP: WebDAV
- catacomb
- DLR: Data Finder
- Launchpad
- DLR Technologiemarketing
- WP: Apache-Lizenz
- WP: Wissensmanagement
- ApacheCon
- FrOSCon
Klingt spannend für CRE-Publikum, aber leider nur die.
Mit den ersten Ausgaben von Raumzeit habe ich Leute für Podcasting und das Thema Weltraum begeistern können, die keine Nerds sind und nicht wissen (müssen), was ein Feed ist.
Die Roboter-Folge war schon viel zu technisch, ich habe die Befürchtung, dass diese auch so wird.
Wieder mehr Universum bitte!
Dies war die schwächste Episode vom sonst sehr hochwertigen Raumzeit-Podcast. Mir als CRE-Hörer gefiel die Episode 14 sowieso am besten =)
Leider schien der Gesprächtspartner nicht sehr motiviert und Tim musste teilweise alles aus im rausquetschen damit er mal auf den Punkt kam und nicht schwammige Umschreibungen benutzte. Vielleicht bin ich als Zuhörer auch nur viel zu speziell.
Vielleicht habe ich meine Erwartungen als ich den Titel gelesen habe etwas zu hoch angesetzt. Aber das war der erste RZ Podcast der mich etwas enttäuscht hat.
Die brennende Leidenschaft für das eigene Fachgebiet und der Wille das ganze solange mit Beispielen zu erklären bis es auch der letzte Verstanden hat, fehlten mit beim Gast ein wenig.
Hi,
habe den Podcast noch nicht gehört. Möchte nur darauf hinweisen, dass die
angegebene Dauer von 02:00:39 die vom letzten Podcast ist.
Gut gesehen. Hab’s geändert. Danke.
Gerne! Aber jetzt ist die Zeit im Binärsystem angegeben 😉
Ich fand die Episode leider auch etwas schwach, vor allem im Vergleich zu der großartigen vorherigen Robotik Folge. Aber ich hoffe, es gibt trotzdem noch mehr Themen aus der Informatik!
anfänger. kriegt man ja richtig angst wenn man das hört
Pingback: Softwaretechnik (Raumzeit-Podcast)
Weniger DLR, mehr Raumzeit bitte!
Ja, ich fand diese Folge auch schwächer. Aber manchmal ist es halt schwierig, etwas aus den Gesprächspartner raus zu bekommen, was jedenfalls für mich verständlich, genüg konkret und damit verwertbar ist.
Ich schließe mich einigen Vorkommentaren an: mehr Universum und Raumzeit. Vermessung Sternensysteme, die Milchstraße, Zeit und Raum. Höre ich immer wieder gerne.
Ich fand die Folge – auch als (zugegeben sehr interessierter) Nicht-Informatiker – ganz gut. Hätte aber noch ein paar mehr Dinge wissen wollen. Zum Beispiel, wie das denn nun mit dem Ada Mythos aussieht. Angeblich sind ja Luft- und Raumfahrt, Fahrzeug- und Waffensteuerung die Haupteinsatzzwecke dafür. Ist Ada in den 35 DLR-Sprachen enthalten, bzw. welchen Anteil nimmt sie ein? Welche Rolle hat allgemein „sicherer“ Code? Spielen solche Konzepte wie Design-by-contract oder formale Softwarebeweise eine besondere Rolle und wird in dem Bereich Forschung betrieben?
Wenn jemand erzählt, dass in seinem Unternehmen auf Kritzel-Papier geplant wird, dann brauchst du mit sowas gar nicht anfangen. Und was der Herr erzählt hat, dass die irgendwelche Philosophie-Studenten (?) als Programmierer einstellen.. Man sieht halt doch immer wieder, dass auch solche Experten nur mit „ganz lauwarmen Wasser kochen“, gerade wenn es keinen großen Wettbewerb gibt. Abgesehen davon gibt es natürlich auch tatsächliche Experten, die nicht soviel Stuss erzählen.
Grundsätzlich kannst du mir – wenn es interessiert – Informationen zu DO-178B besorgen, da kriegt man dann ein besseres Bild wie die Entwicklung von High Integrity-Systemen aussehen sollte. Auch für andere Projekte sollte man wenigstens die Grundlegenden Regeln eventuell für das entsprechende Projekt einmal evaluieren und schauen was nützlich ist.
Die wichtigste Regel ist: Implementation folgt Planung. Das heißt, dass _vor_ dem Programmieren geplant/entwickelt wird. Es wird nicht nur das fertige Produkt geplant, sondern auch der Entwicklungsprozess an sich geplant und dokumentiert. Die Dokumentation sollte größtenteils auch schon stehen bevor implementiert wird – Im Grunde geht es darum, dass verwertbare Spezifikationen und Anforderungen stehen gegen die Man das Produkt validieren kann. Die Validation ist ein Teil des V&V Prozesses (Verifikation & Validierung). Bei der Validierung wird geschaut, ob die Software die geforderte Funktionalität besitzt. Bei der Verifikation wird das Produkt auf Korrektheit geprüft. Hierbei kommen in der Regel entweder symbolische oder numerische/werte- Analysen zum Einsatz. Symbolisch : Es werden logische Aussagen formuliert, die zusammen eine wahre Aussage ergeben müssen. Die Aussagen werden oft automatisch aus Bedingungen erzeugt und Vereinfacht, meistens sogar noch automatisch bewiesen (siehe Frama-C, ANSI C Specification Language, SPARK). Es kann auch per Hand symbolisch verifiziert werden, das wird oft bei kurzen Stücken Assembly getan und ist sehr sehr aufwendig. Bei der Werteanalyse wird der gesamte Definitionsbereich durchlaufen und geschaut, ob das Ergebnis jeweils korrekt und im Wertebereich zu finden ist.
Ada ist fast immer, die Sprache der Wahl (Es gibt noch MISRA-C, MISRA-C++, JSF C++, u.a.) erfordert jedoch eine relativ hohe Kompetenz des Personals, gerade, wenn auch SPARK eingesetzt werden soll. Leider sind die meisten Leute tatsächlich entweder zu dumm, um den Sinn und Nutzen von Ada und allem was dahinter steckt zu verstehen und man trifft oft auf sehr viel Ignoranz und Inkompetenz.
Das war jetzt alles sicher sehr unstrukturiert, ich hoffe es ist trotzdem interessant.
Wenn jemand erzählt, dass in seinem Unternehmen auf Kritzel-Papier geplant wird, dann brauchst du mit sowas gar nicht anfangen.
Es ist doch ein vernünftiger Ansatz, zunächst auf dem Papier eine Skizze/Konzept aufzureißen. Auch innerhalb von Kunstruktionsunternehmen wird am Anfang eine Skizze auf dem Papier gemacht. Ich mache bei meinen Konstruktionen auch erst eine unmaßstäbliche Skizze, dann wird sie maßstäblich neu erzeugt und dann erst in den Rechner übertragen. Funktioniert seit rund 20 Jahren wunderbar.
Das Problem ist nämlich, wenn man Skizzen/Konzepte direkt in einer Software macht, dann ist man sofort innerhalb deren Grenzen gefangen. Es ist schwierig, etwas hinzuzufügen oder wegzunehmen. Auf dem Papier male/schreibe ich was dazu oder radiere es weg, geht innerhalb von Sekunden. Bei Programmen muß ich mich durch Menüs klicken. Manchmal funktioniert ein Programm auch nicht so, wie man es erwartet oder stellt eine Funktion nicht zur Verfügung.
Erst wenn man weiß, was man überhaupt will, dann ist es sinnvoll, die Sachen als Konzeptstudie in den Rechner zu übertragen. Dabei findet auch schon ein Filterungsprozeß statt und man sieht bereits, was möglicherweise funktioniert und was nicht.
Und was der Herr erzählt hat, dass die irgendwelche Philosophie-Studenten (?) als Programmierer einstellen.
[x] Du hast diesen Podcast nicht von Anfang an gehört.
nichts gegen brainstorming, mal ne skizze usw. auf papier, aber alles was darüber hinaus geht, sprich wesentliche ideen und gedanken die der anforderungsanalyse zugrundeliegen, auch, wenn sie nicht direkt zum eigentlichen“entwicklungsprozess“ gehören, sollte man gleich ordentlich machen und traceable machen und archivieren. wenn man ordentlich mit seiner dokumentation anfängt, dann braucht man nur wenig länger als ohne und hat später den vorteil zu wissen, welcher gedanke woher kommt, wenn man etwas ändern möchte. es reicht ja schon das ganze – wenn es nun dem wert des materials entspricht, das per hand auf papier festzuhalten – einzuscannen und im späteren prozess zu referenzieren.
nichts gegen brainstorming, mal ne skizze usw. auf papier, aber alles was darüber hinaus geht, sprich wesentliche ideen und gedanken die der anforderungsanalyse zugrundeliegen, auch, wenn sie nicht direkt zum eigentlichen”entwicklungsprozess” gehören, sollte man gleich ordentlich machen und traceable machen und archivieren. wenn man ordentlich mit seiner dokumentation anfängt, dann braucht man nur wenig länger
Programme engen bei dem Skizzieren/Entwerfen der Ideen ein, sie sind nicht flexibel genug, weil sie immer nach bestimmten Abläufen arbeiten, die nicht unbedingt mit dem Denkprozeß beim Entwerfen kompatibel sind. Ferner ist die Hardware ungeeigenet für solche Tätigkeiten. Im konstruktiven Bereich wird bei uns noch ganz klassisch das A1-Blatt aufs Reißbrett gespannt und darauf skizziert. Das hat nicht nur den Vorteil der Flexibilität, sondern gibt mir immer einen Gesamtüberblick über meinen Entwurf. Das klappt am Bildschirm nicht, egal, wie groß der ist.
Das hat auch nichts mit Brainstorming zu tun, das ist nämlich was völlig anderes.
Sieh Dir doch nur mal an, auf welchem Medium die ersten Entwürfe von Fahrzeugen, Filmen, Kleidung, Häusern usw. erstellt werden. Das ist immer ein Bogen Papier. Erst im weiteren Prozeß, mit der Zunahme des Detailierungsgrades wird das in die Rechner übertragen.
es reicht ja schon das ganze – wenn es nun dem wert des materials entspricht, das per hand auf papier festzuhalten – einzuscannen und im späteren prozess zu referenzieren.
Richtig.
P.S.: Deine Hochstelltaste ist defekt.
ich habe mich nicht über grafik, sondern text ausgelassen. für grafik gelten natürlich andere maßstäbe. thema war nicht flugzeug/kleidung/automobil/haus-entwurf sondern anforderungsanalyse und spezifizierung von software.
falsch
Ich war von dieser Folge der RZ enttäuscht und halte sie für die schwächste der bisher 15 Folgen.
Die Folge war für mich insofern enttäuschend, weil ich mehr Informationen über die Anforderungen an Software, vorallem im Hinblick auf Steuerung und Regelung von Raumfahrzeugen erwartet hatte. Die Frage, welche Kriterien ein Betriebssystem in Satelliten, Raketen, Raumstationen usw. erfüllen muß, wurde nicht gestellt, auch Fragen hinsichtlich zum Test von derartiger Software wurden nicht gestellt. Wie aktuallisiert man ein Betriebssystem in Raumfahrzeugen, wenn sie unterwegs sind oder ist das nicht möglich? Das waren u.a. Fragen, die ich bei diesem Thema erwartet hatte.
Stattdessen gibt es ein langes Gespräch (zwischen zwei durchaus kompetenten Menschen) über verwendete Programmiersprachen, Entwicklungsumgebungen, Lizenzmodellen und wie man Software plant bzw. umsetzt. Alles Themen wo Tim zweifelsohne in seinem Element ist. Letztendlich kann Tim aber auch nicht so aus sich heraus, wie er es beim CRE macht. Man spürt die Ansätze, daß er was bestimmtes sagen will, dann aber doch nicht sagt, was sicherlich ein Zugeständnis an den Auftraggeber ist.
Insofern bleibt für mich nur das Fazit: Diese Folge schwankt zwischen RZ und CRE und kann sich nicht so recht entscheiden, was es nun ist und dringt nicht ins Detail vor. Beide Gesprächsteilnehmer bleiben weit hinter ihrem Potential zurück und wichtige Fragen wurden nicht gestellt und somit auch nicht beantwortet.
Meine Empfehlung an Tim: lad Andreas Schreiber doch mal in einen Deiner CRE ein und versuche die o.g. Fragen hinsichtlich der Anforderungen an die Software zu erörtern. Dann könntet und solltet Ihr Euch auch in Detaildiskussionen zu den Lizenzmodellen, Umsetzungen, Anfoderungen usw. vertiefen.
Ich habe mich sehr gefreut, als ich die Überschrift gelesen habe.
Leider war das nicht so ganz das, was ich im Sinn hatte.
Ich habe gedacht, hier wird mal konkret gezeigt, was denn bei der Softwareentwicklung einer Raumkapsel so alles beachtet werden muss.
* Wie stellt man sicher, dass das Ding am Jupiter auch noch läuft, wie redundant wird so ein System ausgelegt?
* Wie schafft man es, dass so eine Sonde teilweise komplett umprogrammiert wird, weil z.B. eine Navigationskomponente ausfällt?
* Wie sieht es eigentlich aus, wird jede Codezeile einer Missionssoftware von drei unterschiedlichen Gruppen überprüft, oder wie macht man das?
* Gibt es bei solch kritischer Software auch Ansätze von Agilen Entwicklungsprozessen, oder ist alles streng nach Wasserfall?
* Wie sehen die Tests aus, wie simuliert man einen Raumflug?
Das wäre zumindest für mich sehr interessant gewesen. Leider ging es da mehr um interne Software, die ja in jeder größeren Firma entwickelt wird. Das ist aber wesentlich weniger aufregend und leider auch sehr schwammig rübergebracht.
Evtl sollte man da noch mal eine Folge machen, die die konkrete SW Arbeit an einer Sonde beschreibt inkl. der vielen Probleme und Gründe für Ausfälle, die es schon gegeben hat. Da war die Roboter-Folge wesentlich informativer was Software angeht.
Trotzdem natürlich einen großen Dank für die ganze Podcast-Serie!
Hallo Jörg van der Linde,
* Wie stellt man sicher, dass das Ding am Jupiter auch noch läuft, wie redundant wird so ein System ausgelegt?
Zur Beantwortung dieser Frage könnte man schon 100 Seiten Text füllen. Die höchste Redundanz, die ich bisher gesehen habe war 4-fach. Es gibt aber auch Amateur-Funk-Satelliten die bspw. gar keine redundanten Systeme haben. Depends.
* Wie schafft man es, dass so eine Sonde teilweise komplett umprogrammiert wird, weil z.B. eine Navigationskomponente ausfällt?
Z.B.:Auf ein redundantes System umschalten, das andere Neu flashen, Testen, wieder umschalten, dann das redundante System flashen.
* Wie sieht es eigentlich aus, wird jede Codezeile einer Missionssoftware von drei unterschiedlichen Gruppen überprüft, oder wie macht man das?
Peer reviewing ist sicher eine nützliche Methode um Fehler zu finden, genügt aber keinen HI-Anforderungen, da jeder Mensch, auch 5 zusammen Fehler machen können. Fehler müssen von Anfang an ausgeschlossen werden, da wo es geht. Mit Ada wird das zum Beispiel durch eine wohldefinierte Sprachsyntax und ein sehr komplexes Typsystem erreicht. Bspw. kann in Ada ein Typ definiert werden, der Werte zwischen -6.0 und +42.2 annehmen kann, beliebig diskret ist, z.B. in 0.2er Schritten und eine Genauigkeit von 3 Nachkommastellen hat. Da Ada sehr Statisch ist – dass heißt nicht, dass man mit Ada nichts kompliziertes machen kann, sondern, dass fast alle Informationen über Typen, Variablen, Eingabe- Ausgabewerte usw. schon zur Zeit der Kompilierung verfügbar ist – kann hier hervorragend der Programmablauf analysiert und auf Korrektheit überprüft werden.
* Gibt es bei solch kritischer Software auch Ansätze von Agilen Entwicklungsprozessen, oder ist alles streng nach Wasserfall?
In der Regel wird alles Iterativ gemacht. Was es gibt sind v.a. Test Cases. Ansonsten liegt der Schwerpunkt der Optimierung wohl eher beim Prozess als beim Produkt. Auch hier lohnt ein Blick auf DO-178B.
* Wie sehen die Tests aus, wie simuliert man einen Raumflug? Jedes Modul wird getestet und natürlich alle Module zusammen. Das ergibt sich schon durch die erforderliche Validation. Außerdem gibt es beispielsweise Vaakum/Temperatur-Kammern, in die man seinen Satelliten stecken kann. Strahlung lässt sich auch simulieren, Datenübertragung über Ku/S/X-Band lässt sich in einem abgeschirmten Raum machen, ist aber schon komplizierter..
Zu dem Thema lässt sich viel erzählen, ich habe nur mal geschrieben, was mir als erstes durch den Kopf ging zu den einzelnen Punkten, hoffe es passt.
Danke, das war schon mal interessant.
genauigkeit ist bei fixkomma-arithmetik natürlich quatsch, machen wir ein „oder“ aus dem „und“ und es passt.
das DLR kommt mir ehrlich gesagt immer mehr wie ein Hottentotten-Verein vor, …
@hans: Mir kommt dieser Kommentar ehrlich gesagt reichlich unqualifiziert vor. Was außer eine von 15 Podcast-Episoden, die Dir nicht gut gefallen hat, bringt dich zu dieser Einschätzung?
@Alle: Wir haben auf jeden Fall vor, das Thema Softwareentwicklung in der Luft- und Raumfahrt in der Raumzeit noch weiter zu behandeln. Vielleicht haben wir durch die Wahl des Episoden-Titels hier zu allgemeine Erwartungen geweckt. Wir nehmen die Anregungen aus den Kommentaren aber natürlich für weitere Raumzeit-Ausflüge in die Software-Welt mit auf.
— Henning (DLR)
richtig.
Das hört sich gut an, wenn Ihr das Thema nochmal, unter Berücksichtung der Kommentare hier, aufgreifen wollt. Von mir aus kann ein solcher Podcast dann durchaus auch mal drei Stunden lang sein.
Hallo Henning, das hört sich gut an.
Ich freue mich auf weitere Podcasts zu dem Thema.
Evtl wäre es sinnvoll, ein konkretes Projekt zu nehmen und sich dann daran entlang zu hangeln.
Also z.B. eine bekannte Mission, und die damit verbundenen Softwareentwicklungen.
Jörg
Erst einmal vielen Dank an die Macher und Verantwortlichen für die hervorragende Serie von Raumzeit Podcasts.
Sehr interessant fand ich in diesem Podcast die Beteiligung an der freien Softwareszene. Ein konkreter Überblick über die Beteiligungen wäre schön.
Dennoch fiel diese Folge gegenüber den bisherigen ab. Selbst mir als Programmierer von großen Industriemaschinensteuerungen war es nicht möglich, dem Wust von in den Raum gestellten Fachchinesisch zu folgen. Zwar wird zu jedem Thema ein Wikipedia Link gegeben. – Aber leider ist gerade deren Informatikbereich – anders als die große Mehrheit der Wikipedia Artikel – von Spezialisten für Spezialisten geschrieben, so dass ein Einlesen ins Thema damit für Otto Normalleser nicht möglich ist.
Nicht jeder ist auf jedem Gebiet der Software und deren Konzepten firm. Und diesmal hat das sonst großartige Veranschaulichungs- und Zusammenfassungstalent von Tim Pritlove nicht so recht greifen wollen. Es wäre daher erfreulich, wenn man sich dort nicht auf die Wikipedia verlassen und wie bei den bisherigen Podcasts so erklären würde, dass ein Gros an technisch interessierten Personen folgen kann.
Zu den negativen Kommentaren:
Seltsamerweise kann der „Hottentottenverein DLR“ auf großartige Erfolge sowohl bei seinen eigentlichen Aufgaben als auch bei den Podcasts zurückblicken. Ferner kann ich mich an kein einziges Entwicklungsprojekt in unserem Unternehmen erinnern, bei dem bis heute die ersten Ideen nicht auf Papier entwickelt wurden. Keine Zeichensoftware ist flexibel genug, dieses zu ersetzen.
Gruß
Jesper
Der obigen Mehrheit anschließend: Die Folge war schwach. Aus meiner Sicht lag das nicht am Thema oder Inhalt, sondern am sehr zurückhaltenden Gesprächspartner von Tim. Ein Dialog funktioniert eben nur zur Zweit 🙂
Einen ähnlichen Eindruck hatte ich auch in der vorherigen Folge über die Atmosphäre. Hier wirkte das Gespräch teilweise etwas verkrampft und stockend – auch wenn Tim es großartig und mit viel Lachen in die richtige Sphäre gelenkt hat.
Dennoch, großartiger Podcast! Klasse Moderator und Produzent und weiter machen!
Kann mich auch nur anschließen. Die Folge klingt vom Titel sehr spannend kratzt aber nur an der Oberfläche. Ich dachte ehrlich gesagt beim Hören, dass nach der ersten Stunde es richtig in die Vollen geht. Ein Blick auf die Restlaufzeit hat dann doch große Ernüchterung hervorgerufen.
Was mir insbesondere unklar geblieben ist:
Welche Methoden der Softwareentwicklung werden denn nun vorwiegend von diesem Institut empfohlen/eingesetzt? Scheinbar gibt es im DLR ja doch ganz spezielle Anforderungen an den Softwareentwicklungsprozess an sich. So klang es jedenfalls raus. Und wie unterscheiden sich diese dann von den gängigen Softwareentwicklungsprozessen. Das fehlte mir etwas. Vllt. hab ich es auch einfach nicht richtig rausgehört.
Vllt. waren meine Erwartungen als begeistertet CRE-Hörer auch etwas zu hoch an diese Folge. 😉
Nett zum Einstieg, aber tatsächlich etwas generisch, da sehr starker Fokus auf „Back Office“. Ich hoffe auf weitere, deutlich vertiefende Folgen zu konkreten DLR- und vor allem ESA-Projekten, zum Beispiel zu den Fragen:
– Wie läuft das Management von redundanter Programmierung von kritischen Projekten? Lassen sich Standardmethoden des Software Engineering übertragen?
– Wie läuft die Verifikation von kritischen Code-Teilen (Unit-Tests, formale Verifikation etc.)?
– In welcher Programmiersprache werden Raumsonden programmiert (Assembler, C, Eigenentwicklungen?) und wie kann man sich das Betriebssystem auf solchen Geräten vorstellen?
– Welche Hardware steckt in Satelliten und Raumsonden (Rechenleistung, Speicher, Modifikationen für erhöhte Robustheit)?
In der Folge wird unter anderem erwähnt, dass ihr den Wissenschaftlern behilflich seid, Python so weit zu lernen, dass sie ihre alten, bspw. in C/F77 entwickelten Routinen mit einer grafischen Oberfläche versehen können, bspw. zur Parametereingabe.
Schade, dass ich nicht beim DLR arbeite, denn genau so eine Hilfe bräuchte ich.
Könnt ihr mir also ein gutes Buch oder eine andere Quelle empfehlen, mit der jemand, der keine Zeit/Lust hat sich tief in Python einzuarbeiten, schnell in der Lage ist eine Oberfläche zur Steuerung von solchen Routinen (C/F77) zusammenbasteln kann.
Danke für jeden Tipp und auch sehr herzlichen Dank für die sehr interessante Podcastreihe.
Den Raumzeit Podacst finde ich im Großen und Ganzen wirklich sehr gelungen, diese Folge hat mich allerdings ziemlich enttäuscht. Vom Gesprächspartner war nicht viel zu hören, was denn nun die tatsächliche Softwareentwicklung im Raumfahrtbereich betrifft. Aussagen wie
– man zeigt den Studenten, wie man eine korrekte Anforderungsanalyse durchführt
– Anwender werden in Programme wie Eclipse eingeführt
– man stellt den Entwicklern Tools (hier sogar einfach nur eingekaufte 0815-Software von der Stange) zur Verfügung
oder alles rund um das Thema Lizenzmodelle hinterlassen ja fast schon den Eindruck, als würde der Gesprächspartner irgendwo im Support arbeiten. Hauptsache in jedem 2. Satz das Wort Softwareengineering verwendet, aber zum eigentlichen Thema war dann noch eher wenig dabei. Schade. Hier hatte ich mir mehr von der Sorte erwartet, wie auch schon in einigen Kommentaren erwähnt worden ist, z. B.
Die Folge war für mich insofern enttäuschend, weil ich mehr Informationen über die Anforderungen an Software, vorallem im Hinblick auf Steuerung und Regelung von Raumfahrzeugen erwartet hatte. Die Frage, welche Kriterien ein Betriebssystem in Satelliten, Raketen, Raumstationen usw. erfüllen muß, wurde nicht gestellt, auch Fragen hinsichtlich zum Test von derartiger Software wurden nicht gestellt. Wie aktuallisiert man ein Betriebssystem in Raumfahrzeugen, wenn sie unterwegs sind oder ist das nicht möglich? Das waren u.a. Fragen, die ich bei diesem Thema erwartet hatte.
Vielleicht habe ich hier ein wenig übertrieben. Damit möchte ich aber nicht provozieren sondern nur verdeutlichen, dass man aus dem Thema doch so viel herauskitzeln kann. Man muss ja noch nicht mal kitzeln: das Thema ist so ausgiebig, da würde glatt für mehrere Folgen ausreichen …
Viele Grüße, danke für die vielen tollen Folgen (Ausnahmen bestätigen die Regel) und macht bitte noch ganz lange so weiter.