Open Access

Integrierte Navigationssysteme (INS) auf Schiffen leisten einen großen Beitrag zu sicheren Navigation, um kritische Situationen zu umgehen oder zu entschärfen. Damit können INS als sicherheitsrelevante Systeme bezeichnet werden. Neben durchgängiger Redundanz, Diagnose von Komponenten zur Laufzeit und durchgeführter FMEA für die Typzulassung des INS, weisen diese keine weiteren Mechanismen auf, um das System im Fehlerfall vor Ausfall oder Fehlfunktion zu schützen, wodurch das System in einen kritischen Zustand übergehen kann. Weitere Maßnahmen sind notwendig, weil die Integrationsgrade der Navigationssysteme und Interaktionen mit vielen unterschiedlichen Systemen stetig zunehmen. Damit ein INS in Zukunft weiterhin dem Stand der Technik entspricht, müssen aktuelle Anforderungen aus Standards, wie dem IEC 61162-460 hinsichtlich Safety & Security erfüllen, damit das Risiko erhöhter Integrationsgraden auf ein vertretbares Maß gesenkt werden kann. Um das System vor Übergängen in kritische Zustände zu bewahren und einen Sicherheitslevel zu erreichen, der zukünftig den Anforderungen an Bord genügt, wird im Rahmen dieser Arbeit neben den gültigen Standards und Normen für INS die Funktionale Sicherheit betrachtet. Dazu wird ¨ die Grundnorm IEC 61508 und die abgeleiteten Normen für entsprechende Industriebereiche ¨ betrachtet. Für den Seeverkehr gilt hervorgehoben die UN-Konvention SOLAS von 1974. Die Festlegungen aus dieser Konvention spiegeln sich in Normen und Standards, wie auch in Gesetzen der Staaten wider. Der Fokus der Standardisierungsgremien liegt nach wie vor auf dem Menschen und der Unterstützung durch das INS. Dabei sollen Fehler des Menschen vermieden, Ausfälle erkannt und Warnungen erzeugt werden. Mit dem Standard IEC 61162-460 beginnt die Standardisierung der Sicherheit (Safety & Security) und Funktionalen Sicherheit des INS. Durch eine Rekapitulation von Serviceeinsätzen wurde erkannt, dass in vielen Fällen ein Ausfall oder eine Fehlfunktion dadurch entstand, dass eine fehlerhafte Konfiguration vorlag. Die hohe Konfigurierbarkeit des INS ist ein Vorteil, birgt jedoch die Gefahr der Fehlkonfiguration. Die Auswertungen der Fehlerzustände und Ausfälle ergab, dass eine Diagnose der Konfiguration durchgeführt werden muss. Diese Diagnose soll bereits zur Konfigurationszeit durchgeführt werden (Onlinediagnose). Dabei wird die erstellte Konfiguration gegen Bedingungen geprüft, die Restriktionen der verwendeten Hardware (z.B. Überlast) oder die Systemintegrität (z.B. geforderte Redundanz, Einbaupositionen) abbilden. Die Diagnoseabdeckung des Systems wird neben der Laufzeit auf die Konfigurationszeit (Installation und Inbetriebnahme) erweitert. Für höchst konfigurierbare Systeme, wie das INS von Raytheon Anschutz, können bis zu 29% der Fehleranteile im Lebenszyklus eines Systems vermieden werden. Die vorliegende Arbeit bietet einen Ansatz zur Erweiterung der Diagnosefähigkeiten des Systems auf die Konfigurationszeit. Bestimmte Bedingungen, abhängig von verwendeter Hardware, Größe des Gesamtsystems können bereits bei Anfertigung der Systemkonfiguration überprüft werden. Plausibilitäts- und Integritätsprüfungen, wie Einbaupositionen, notwendige Redundanzen, korrekte Sensorverbindungen können zusätzlich überprüft werden. Das System erlangt Kenntnis über sich selbst und seine Konfiguration. Diese Kenntnis verknüpft mit den Bedingungen, erlaubt es dem Bedienern nützliche Hinweise und Warnmeldungen zu geben, wo die Systemkonfiguration mögliche Risiken für gefährliche Ausfälle des Systems birgt. Die ausgelieferten Systeme werden robuster und die Anzahl und Dauer der Serviceeinsätze wird gesenkt und Kosten eingespart. Die Ausfallrate der Systeme sinkt, wodurch sicherheitsgerichtete Funktionen, wie Collision Avoidance mit einer höheren Zuverlässigkeit verwendet werden können. Eine rechnerische Überprüfung der verwendeten Komponenten und Systemarchitektur zeigt eine mögliche SIL-Einstufung des Systems.

Cloud-Computing ist das Schlagwort der letzten Jahre in der Informationstechnologie schlechthin. Anbieter von Cloud-Lösungen versprechen Einsparungen bei Infrastrukturkosten, eine schnellere Serviceverfügbarkeit, eine bessere Performanz und kürzere Entwicklungszyklen. Viele Unternehmen reizt deshalb der Umstieg auf eine Cloud-Infrastruktur. Doch mit einem einfachen Umzug der Anwendungen ist es selten getan. Diese Arbeit zeigt auf, wie Softwareanwendungen aufgebaut sein müssen, damit sie aus einer Cloud-Infrastruktur einen optimalen Nutzen ziehen können. Zudem sind auch organisatorische Änderungen nötig, um moderne Cloud-Anwendungen zu entwickeln. Auch diese Änderungen werden besprochen. Häufig stehen Unternehmen vor dem zusätzlichen Problem, dass Anwendungen seit mehreren Jahren in Betrieb, aber technisch veraltet sind. Diese Legacy-Anwendungen sind geprägt durch fehlendes Entwicklungs-Know-how und eine lange Einsatzphase ohne Modernisierung und Restrukturierung. Die Plattformen, die sie nutzen, sind oft veraltet und der technologische Sprung auf eine Cloud-Umgebung deshalb sehr groß. Diese Arbeit erklärt, was Legacy-Software ist, wie sie entsteht, und wie mit ihr verfahren werden kann. Zudem wird das Thema Softwaremigrationen erklärt. Verschiedene Migrationsarten werden vorgestellt, und der exemplarische Ablauf einer Softwaremigration aufgezeigt. Das Ergebnis der Arbeit ist ein Konzept für Migrationsstrategien von Legacy-Anwendungen. Es wird für ein großes deutsches Versicherungsunternehmen entwickelt, das die Einführung einer Cloud-Infrastruktur plant. Der Umgang mit Altanwendungen, die bereits nicht mehr in die geplante Laufzeitumgebung passen, die jedoch weiterhin benötigt werden, ist derzeit ungeklärt. Er soll mit Hilfe dieser Arbeit festgelegt werden.

Die Softwareentwicklung wird in der Automobilbranche aufgrund der Komplexität der Fahrzeuge und Steuergeräte immer wichtiger. Neben der Komplexität der Fahrzeuge stehen die Hersteller einem Marktumfeld gegenüber, dass sich immer schneller wandelt und in immer kürzerer Zeit neue Innovationen einfordert. Einen Großteil der Softwareentwicklung vergeben die HerstellerInnen an externe LieferantInnen, da das Wissen über die Softwareentwicklung meist nicht bei den HerstellerInnen vorhanden ist. Die Auswahl der LieferantInnen erfolgt oftmals mit Hilfe von Prozessbewertungen nach Automotive SPICE. Dies soll sowohl die Qualität der Software als auch die Prozessfähigkeit und Termintreue der LieferantInnen sicherstellen. Daneben fordern die HerstellerInnen von den LieferantInnen eine flexiblere Arbeitsweise, damit neue Anforderungen auch innerhalb laufender Softwareprojekte bearbeitet werden können. Aufgrund dieser geforderten Flexibilität ändert sich das Vorgehen der Softwareentwicklung in der Automobilbranche von einem sequenziellen Ansatz hin zu immer agileren Herangehensweisen. Diese Arbeit untersucht anhand von sechs Interviews mit Fachgrößen aus dem agilen Umfeld, wie sich die Anforderungen von Automotive SPICE auf die agile Softwareentwicklung auswirken. Als Beispiel für ein agiles Vorgehensmodell zieht die Arbeit Scrum in Verbindung mit dem Nexus Framework heran. Begleitet wird dieses Vorgehensmodell von agilen Praktiken. Daneben betrachtet die Arbeit das agile Manifest mit seinen Werten und Prinzipien, welche die Grundpfeiler der agilen Softwareentwicklung darstellen. Ein Abgleich der Ziele von Automotive mit der agilen Softwareentwicklung ergänzt die Untersuchung. Die Auswertung der Interviews hat gezeigt, dass der Einsatz agiler Praktiken, wie Pair Programming und Test-Driven Development, auch im Rahmen von Automotive SPICE unter bestimmten Bedingungen möglich ist. Primäre Ziele von Automotive SPICE sind die Prozessverbesserung, die Kosten- und Termineinhaltung und die Planung. Die Prozessverbesserung stimmt mit den agilen Prinzipien überein. Planung, Termin- und Kosteneinhaltung, können Organisationen durch den Einsatz agiler Methoden wie Scrum wesentlich besser erreichen, als es mit traditionellen Methoden möglich ist. Die Standardisierung von Prozessen ermöglicht es den Unternehmen Prozesse wieder zu verwenden und reduziert dadurch die Aufwände bei der Errichtung neuer Projekte. Dies wiederum kommt den agilen Prinzipien entgegen. Für die erfolgreiche Umsetzung der Anforderungen aus Automotive SPICE in agilen Teams und Unternehmen werden konkrete Handlungsempfehlungen gegeben. Die Grenzen dieser Arbeit und aus der Arbeit heraus aufgekommene Forschungsfragen, werden im Anschluss diskutiert.

Die Erstellung von Software ist mittlerweile einer der bedeutendsten Wirtschaftsfaktoren weltweit, erkennbar an der Zugehörigkeit der am schnellsten wachsenden Unternehmen zur Software-Branche. Die Softwareentwicklung hat sich in den letzten Jahrzehnten in ihrer Methodik stark weiter entwickelt, weg von sequentiellen Phasen (Sammlung der Anforderungen, Implementierung, Test, Auslieferung) hin zu agilen, iterativ-inkrementellen Methodologien und Frameworks (u.a. Scrum) mit häufiger Auslieferung der Software. Trotz einer starken Verbreitung agiler Methoden in der Softwareentwicklung scheinen die vertraglichen Modelle für die Vergabe von Softwareprojekten an Dritte noch stark traditionell aufgebaut zu sein und sich an Festpreisen und Wasserfall-Vorgehen zu orientieren. In dieser Arbeit wird der Forschungsfrage nachgegangen, dessen erster Teil auf die Verbreitung agiler Vertragsmodelle abzielt. Der zweite Teil der Forschungsfrage fokussiert Gründe, die österreichische Unternehmen dazu veranlassen, durch die Anwendung traditioneller Vertragsmodelle auf die Vorteile agiler Methodologien der Softwareentwicklung zu verzichten. Im Vergabeportal TED (Tenders Electronic Today) der Europäischen Union müssen Aufträge der öffentlichen Hand neben einer allfälligen nationalen Bekanntmachung auch EU-weit ausgeschrieben werden, sofern sie einen gewissen Auftragswert überschreiten. Dieser Schwellenwert liegt für Softwareprojekte bei € 144.000.-. Ausschreibungen von Softwareprojekten im Zeitraum von zwei Jahren wurden im Zuge dieser Arbeit abgefragt und hinsichtlich des Vorkommens agiler Schlüsselwörter analysiert. Aufgrund der Sprachabhängigkeit dieser Abfragemethode wurden nur jene Ausschreibungen berücksichtigt, die in Deutsch oder Englisch verfasst wurden. Durch diese Datenabfrage kann der erste Aspekt der Forschungsfrage beantwortet werden: Der Anteil von Ausschreibungen unter Verwendung agiler Vertragsmodelle an der Gesamtanzahl der Ausschreibungen im Softwareumfeld ist mit 0,11 % äußerst gering. Selbst der Anteil von Ausschreibungen für Softwareprojekte mit agiler Methodik ist mit 1,17 % sehr klein. In einer Reihe von semistrukturierten Experteninterviews wurden in einer qualitativen Erhebung österreichische Fachgrößen gefragt, was die wichtigsten Gründe für ihr Unternehmen sind, agile Vertragsmodelle nicht anzuwenden. Die genannten Gründe sind je nach Modell und Fachgröße unterschiedlich, können jedoch in den folgenden Kategorien zusammengefasst werden: • fehlende Vergleichbarkeit des Preises • Risiko, Unsicherheit und mangelndes Vertrauen • Herausforderungen bei der Vergabe • mangelndes Verständnis und Kenntnis der Modelle Zu den jeweiligen Gründen werden konkrete Handlungsempfehlungen gegeben, die eine Anwendung dennoch möglich machen könnte. Die Limitierungen dieser Arbeit und etwaige neu aufgeworfene Forschungsfragen werden im Anschluss diskutiert.

Unternehmen müssen heute schnell am Markt agieren und auf die Bedürfnisse und Anforderungen der Kunden eingehen, um wettbewerbsfähig zu bleiben. Um diesen Anforderungen als Unternehmen gerecht werden zu können, bedarf es innovativen Informationssystemen mit flexiblen Softwarearchitekturen. Die Unternehmenskultur kann in Unternehmen eine starke Position einnehmen, wenn Veränderungen in der Unternehmensstrategie vorgenommen werden. Die Veränderung oder Einführung einer neuen Softwarearchitektur eines Informationssystems stellt hierbei eine solche Veränderung in der Strategie dar. Diese Arbeit beantwortet die Frage, wie sich die Kultur in einem Unternehmen und Softwarearchitektur gegenseitig beeinflussen. Hierzu werden zunächst die theoretischen Grundlagen zu Unternehmenskultur und Softwarearchitektur dargelegt. Anschließend wird der mögliche Einfluss der Unternehmenskultur auf die Softwarearchitektur mittels fünf Dimensionen der Unternehmenskultur beschrieben und dadurch deduktiv 59 Hypothesen zur Wirkungsbeziehung generiert. Das Ergebnis der Arbeit ist, dass Unternehmenskultur durch die gemeinsam geteilten Werte das Verhalten des Softwarearchitekten im Architekturzyklus und somit schließlich auch die entworfene Softwarearchitektur beeinflusst. Ebenso stellt die Unternehmenskultur ausgehend von verschiedenen Dimensionen Qualitätsanforderungen an die Softwarearchitektur. Der mögliche Einfluss der Softwarearchitektur auf die Unternehmenskultur wird in der Arbeit am Beispiel des Microservice-Architekturstils beschrieben. Die Einführung oder Veränderung einer Softwarearchitektur führt zu einer Veränderung der Unternehmenskultur, in dem sie gegenwärtige grundlegende Annahmen und Werte in Frage stellt. Ebenso kann eine neue oder veränderte Softwarearchitektur sich auf die Rahmenbedingungen in der Ablauf- und Aufbauorganisation des Unternehmens auswirken. So wird gezeigt, dass das Modularisierungskonzept des Microservice-Architekturstils verschiedene Dimensionen der Unternehmenskultur positiv begünstigen kann.