L1-Risiken und Herausforderungen der industriellen Softwaretechnik

Soll möglichst vielfältige Funktionen unterstützen.

Ist oft ein Teil einer komplexen Anwendungslandschaft und über technische Schnittstellen mit vielen anderen Softwaresystemen verbunden.

Ein Softwaresystem wird häufig von vielen Anwendern benutzt.

Oft besteht die Anforderung, dass ein Softwaresystem auf möglichst vielen Geräten und/oder unter verschiedenen Betriebssystemen funktionieren soll.

Ein Softwaresystem soll, nachdem es in Betrieb genommen wurde, möglichst in vielfacher Hinsicht erweiterbar sein.

Ein Softwaresystem wird in der Regel von vielen Personen erstellt.

Ein Softwaresystem besteht meistens aus vielen verschiedenen Komponenten und Teilsystemen.

Nicht anfassbar

Bestandteile der SW und deren Abhängigkeiten können nicht angeschaut werden - Der Baufortschritt kann nicht so schnell ermittelt werden.

Es handelt sich um teure, komplexe und unternehmenskritische Systeme die in keiner natürlichen Weise Darstellbar sind.

Korrektheit - Damit geprüft werden kann, ob die SW richtig ist.

Zuverlässigkeit - Dauerhaft bei geschäftlichen Aktivitäten einsetzbar.

Robustheit - Bei unerwarteter Bedienung, soll sich die SW tolerant zeigen und keine inkonsistenten Daten oder unkontrollerbaren Fehler hervorbringen.

Usability - Benutzerfreundlich und einfach anwendbar.

Performanz - Anforderungen an das Antwortzeitverhalten und den Ressourcenbedarf von SW-Systemen. Bei verteilten Systemen (Viele User greifen gleichzeitig darauf zu) oder der Bearbeitung großer Datenmengen.

Wartbarkeit - SW Systeme werden oft über viele Jahre betrieben und müssen deshalb an sich ändernde Umstände angepasst werden (Marktbedingungen, Gessetze, Technologie). ÄNDERUNGEN WIRTSCHAFTLICH SINNVOLL. Mit zunehmender Lebensdauer nimmt die Wartbarkeit der SW ab bis ein neues System dieses ersetzt.

Wiederverwendbarkeit - Mit der SW oder Teilen daraus einen anderen Kontext zu verwenden.

Portierbarkeit - Aufwand, um SW auf eine Plattform lauffähig zu machen.

Interoperabilität - Wie viel Aufwand ist nötig, um das System mit einem anderen zu verbinden? Anwendungsübergreifende Systeme sind der Standard der Zeit.

Synonym - Software engeenering

Strukturierte und methodische Planung, Erstellung und Weiterentwicklung von Softwaresystemen sowie deren Betrieb

„Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen. Zielorientiert bedeutet die Berücksichtigung z. B. von Kosten, Zeit, Qualität.“

Die Erstellung von komplexen industriellen Informationssystemen bedarf teils mehrere dutzend Personen über einen langen Zeitraum hnweg.

Diese Systeme können nicht einfach nach der Intuition des Projektleiters erstellt werden, da sonst Chaos entsteht.

Es erfordert Prinzipien, Methoden und Werkzeuge

Die Disziplin ist vergleichsweise jung (ca. 45 Jahre).

Die Komplexität steigt fortlaufend weiter durch leistungsfähigerer HW, ausdrucksstärkerer Programmiersprachen, der Vernetzung von Rechensystemen, dem Ausbau von Übertragungskapazitäten, der Mobilisierung von Rechnersystemen und immer leistungsfähigeren Entwicklungswerkzeugen.

Im Gegensatz zur Elektrotechnik oder Architektur sind dem SW Engeneering keine natürlichen Grenzen gesetzt. Die Mächtigkeit der SW Systeme ist von der Abstraktionsfähigkeit (Abstrakte und logische DInge) und der Kommunikationsfähigkeit der beteiligten Personen begrenzt. Erfahrungen und Erkenntnisse spielen eine wichtige Rolle.

Aufteilung des SW Projekts in verschiedene Aktivitäten und die Verteilung der Mitglieder in Softwareteams mit jeweils eigenen Aktivitäten, Verantwortlichkeiten und Zielkonflikten zwischen den Rollen.

Patterns - (Muster) Einsatz von organisatorischen und technischen Strukturen die sich über mehrere Projekte hinweg bewährt hat.

Vor der Fertigstellung

1. Zentrale Anforderungen stellen sich im Laufe des Projekts als nicht realisierbar dar. Ursache: Ständige Änderungen, überzogene Erwartungen, zu spät erkannte technische, organisatorische oder gesetzliche Rahmenbedingungen.

2. Kosten des Projekts sind vor fertigstellung überzogen und eine weitere belastbare Kostenschätzung ist nciht auszumachen.

3. Streit unter Mitgliedern des Projekts machen eine weitere Zusammenarbeit unmöglich.

Ausgeliefertes System kann nicht eingesetzt werden

1. Wesentliche fachliche Funktionen fehlen oder sind falsch.

2. Qualitätseigenschaften wurden nicht erfüllt (Performanz, Sicherheit)

3. Nicht bedienerfreundlich genug. Kompliziert, Elemente nicht auffindbar.

Wartung und Weiterentwicklung erzeugt im System mehr Probleme

1. Konsequenzen des Wartungsteams wurden nicht richtig abgeschätzt.

2. Viele kleine Wartungsarbeiten über Jahre hinweg degenerieren die interne Struktur des Systems. Der WIrtschaftliche Nutzen steht in keinem Verhältnis zum Aufwand von sogar kleinen Wartungen

3. Wissen der Altsysteme fehlt, die Programmierer nicht mehr verfügbar

Anfangs ist das Ziel zu ungenau definiert, um einzelne Elemente und Funktionen bestimmen zu können.

Anforderungen an das zu erstellende System können erst im Verlauf des Softwareprozesses erkannt werden. Allerdings sind die Anforderungen der Ausgangspunkt alle Aktivitäten des Projekts. Meist werden erkannte Anforderungen von Anwendern und Kunden erst nach der ersten Version erkannt.

Dilemma der SW Programmierer: System entwickeln, ohne das Anforderungen klar sind? Iterativer Vorgang mit Kunden, bis gewünschtes Ergebnis erfüllt wird. Diese Situation verschlimmert sich, weil i.d.R. viele Anspruchsgruppen ihre Anforderungen vorgeben.

Ändernde oder sich wiedersprechende Anforderungen durch rechtliche, Marktbedingte oder technische Einflüsse können das Projekt scheitern lassen.

Fehlendes Fachwissen spezifischer Industriezweige sind weitere Ursachen für das Scheitern von Projekten.

Die SW Programmierer müssen in der Lage sein die fachlichen Zusammenhänge über Systemgrenzen hinaus zu erkennen. Nötiges Fachwissen hilft bestehende Lücken selbstständig zu identifizieren und zu lösen.

Zu starker Fokus auf eingesetzte Technologien und der Nutzen der Anwender fällt in den Hintergrund, aber die fachlichen Probleme der Anwender haben höhere Priorität als die neusten Technologietrends.

Besonders in Entwicklungsprojekten führt die mangelnde Kommunikation unter verschiedenen Abteilungen zu scheiternden Projekten, denn jede Organisationsabteilung hat ganz eigene Vorstellungen.

Wirtschaftliche Ungewissheit

1. Darstellung mit “Cone of Uncertainty”. Y Achse für Ungewissheit, X Achse für Dauer des Projekts. Die Gesamtkosten können zu Beginn vom Ist stark abweichen und werden im Verlauf des Projekts immer genauer. Präzise Vorhersage, wie bei Industrieproduktionen ist i.d.R. nicht möglich.

Technologische Ungewissheit

1. Das technische Zielbild ist anfangs ungenau und bietet einen großen technischen Spielraum. Zum Ende des Projekts wird die finale technische Lösung immer konkreter. Da die Anforderungen im Entwicklungsverlauf sich ändern, werden Lösungen fortlaufend angepasst.

Kommunikation

1. Beinhaltet den Einbezug von Stakeholdern und die angemessene Kommunikation mit diesen. Die Stakeholder werden in die Aspekte der Qualitätssicherung und Entscheidungenfindung mit einbezogen.

Zielkonflikte

1. Das magische Dreieck: Kosten, Qualität, Zeit. WIrd ein Aspekt hervorgehoben, erleidet ein anderer Aspekt ein Defizit.

Komplexität

1. Dingliche Komplexität (Viele technische Komponenten, viele Schnittstellen zu anderen Systemen, viele implementierte Funktionen) und die Immaterialität (Abstraktionsproblem). Der Einsatz von grafischen Softwaremodellen bietet die einzige Lösung, welche statische und dynamische Aspekte berücksichtigt. Die Prämissen der Unsicherheit und Erkenntnisgewinn veranlassen die organisatorische und die technische Planung in Phasen einzustufen.

2. Analysis Paralysis - Oft wird versucht die Komplexität durch detaillierte Planungen mit unterschiedlichen Verläufen zu planen und möglichst alle Eventualitäten zu bedenken. Es folgen unangemessen hohe Planungsaufwendungen.