Grundlagen der industriellen Softwaretechnik

Das Steuerwerk übernimmt in der CPU die Rolle des Koordinators. Es ist dafür zuständig die auszuführenden Befehle eines Programms in der richtigen Reihenfolge aus dem Speicher in dieCPU zu laden, zu interpretieren, Quelle und Ziel der zu verarbeitenden Daten mit dem Rechenwerk zu verschalten und dem Rechenwerk mitzuteilen, welche Berechnung es mit den Daten durchführen soll. Das Rechenwerk ist die einzige Komponente des Rechners in der Berechnungen durchgeführt werden. Das Rechenwerk verfügt über eine Menge von ausführbaren arithmetischen und logischen Funktionen. In ihm werden in Rechnersystemen alle Operationen im Binärsystem durchgeführt.

Server: bezeichnet Rechner, die Funktionen anbieten, die von anderen Rechnern über ein Kommunikationsnetz
aufgerufen werden können.
Client: Rechner, die von Servern angebotene Dienste in Anspruch nehmen Kommunikationsnetz: Netz zur Kommunikation zwischen Rechnersystemen. Es leitet Nachrichten von einem Rechner zu einem anderen.
Nachricht: über das Kommunikationsnetz zwischen Rechnern versendete Informationen

• Der Browser (Client) wird benutzt, um in einem Online-Shop (Server) etwas zu bestellen.
• Der Laptop (Client) soll ein Dokument über einen Netzwerk-Drucker (Server) ausdrucken.
• Das Mobiltelefon (Client) ruft die aktuellen Wetterdaten von einem Wetterdienst (Server) ab.

Anwendungsschicht, Darstellungsschicht, Sitzungsschicht, Transportschicht, Vermittlungsschicht, Sicherungsschicht, Bitübertragungsschicht

Anwendungsschicht, Transportschicht, Internetschicht, Host-zu-Netz-Schicht

Mit dem Begriff betriebliches Informationssystem bezeichnen wir gewerblich eingesetzte Softwaresysteme und deren Systemkontext. Mit der Einschränkung auf gewerbliche Nutzung werden die Softwaresysteme in den Vordergrund gestellt, die mittelbar oder unmittelbar zum Erreichen des Ziels einer Organisation eingesetzt werden. Dabei wird nicht nur das Software-system an sich betrachtet, sondern mit seinem Systemkontext auch die Schnittstellen zu den Nutzern des Systems sowie technische Schnittstellen zu anderen Systemen.

• Kommunikationssysteme
• Querschnittssysteme
• Operative Systeme
• Dispositive Systeme

Operative Systeme unterstützen gezielt Geschäftsprozesse und Aktivitäten in Organisationen. Von allen Systemklassen sind die operativen Systeme am stärksten auf die wertschöpfenden und unterstützenden Geschäftsprozesse von Organisationen hin angepasst. Enterprise Resource Planning (ERP) Systeme, wie zum Beispiel von SAP hergestellt, sind ebenfalls hauptsächlich zu den operativen Systemen zu zählen. Dispositive Systeme dienen der Unterstützung von Planungs- und Entscheidungsprozessen. Typische dispositive Systeme sind Data Warehouse und Business Intelligence Lösungen. In ihnenwerden gezielt bereinigte und verdichtete Daten aus den operativen Systemen über Abläufe, Prozesse, und Geschäftsvorfällen abgelegt.

.

• Ein Softwaresystem muss möglichst vielfältige Funktionen unterstützen.
• Ein Softwaresystem ist Teil einer komplexen Anwendungslandschaft und über technische Schnittstellen mit vielen anderen Softwaresystemen verbunden.
• Ein Softwaresystem wird von vielen Anwendern benutzt.
• Ein Softwaresystem soll auf möglichst vielen Geräten unter verschiedenen Betriebssystemen funktionieren.
• Ein Softwaresystem soll, nachdem es in Betrieb genommen wurde, möglichst in vielfacher Hinsicht erweiterbar sein.
• Ein Softwaresystem wird von vielen Personen erstellt.
• Ein Softwaresystem besteht aus vielen verschiedenen Komponenten und Teilsystemen.

Software kann man nicht anfassen. Software ist immateriell. Ein fertiges Softwaresystem manifestiert sich als sehr lange Reihe von 0 und 1 auf einer Festplatte oder einer DVD.

Korrektheit, Zuverlässigkeit, Robustheit, Usability (deutsch: Gebrauchstauglichkeit), Performanz, Wartbarkeit, Wiederverwendbarkeit, Portierbarkeit, Interoperabilität

„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.“

• Verfügbarkeit von leistungsfähigerer Hardware
• Verfügbarkeit von ausdrucksmächtigeren Programmiersprachen
• Vernetzung von Rechnersystemen
• Ausbau von Übertragungskapazitäten
• Mobilisierung von Rechnersystemen
• Verfügbarkeit von leistungsfähigeren Entwicklungswerkzeugen

Da Softwaresysteme immateriell sind, werden sie in ihrer Größe und Vielfalt nicht durch natürliche oder physikalische Gesetze begrenzt. Im Gegensatz zu anderen Disziplinen, wie zum Beispiel Architektur oder Elektrotechnik, gibt es nahezu keine natürlichen Beschränkungen wie Schwerkraft, Reibung oder Widerstand.

• Zentrale Anforderungen stellen sich im Projektverlauf als nicht realisierbar heraus.
• Die Kosten für das Projekt sind bereits völlig aus dem Rahmen gelaufen, bevor das System einsatzbereit ist.
• Mitglieder oder verschiedene Organisationseinheiten innerhalb des Projekts sind grundsätzlich anderer Auffassung beziehungsweise zerstritten.

• Bei der Inbetriebnahme stellt sich heraus, dass wichtige fachliche Funktionen fehlen oder falsch umgesetzt wurden.
• Vom Kunden geforderte Qualitätseigenschaften werden nicht erfüllt.
• Das System wird von den Anwendern nicht angenommen.

• Das mit der Wartung beauftragte Team kann die Konsequenzen seiner Handlung nicht abschätzen.
• Durch viele kleine Wartungsarbeiten und Anpassungen ist die interne Struktur des Systems über die Jahre hinweg degeneriert.
• Es ist kein Wissen über die im Altsystem eingesetzten Technologien verfügbar.

Anforderungen an das zu erstellende System werden erst im Verlauf des Softwareprozesses erkannt. Allerdings bilden die Anforderungen an das System den Ausgangspunkt für alle weiteren Aktivitäten innerhalb eines Softwareprojektes. In der Regel werden relevante Anforderungen von Anwendern und Kunden erst erkannt, nachdem sie eine erste Version des Systems gesehen haben.

Das Entwicklungsteam muss die von den Stakeholdern formulierten Anforderungen fachlich verstehen, damit es ein benutzbares Softwaresystem ausliefern kann. Weil industrielle Softwaresysteme der heutigen Zeit in der Regel über eine Vielzahl technischer Schnittstellen in komplexe Anwendungslandschaften eingebunden sind, muss das Entwicklungsteam in der Lage sein, die fachlichen Zusammenhänge über Systemgrenzen hinweg zu kennen. Außerdem kann ein Projektteam mit Fachwissen über den Anwendungsbereich sicherer mit unklaren Anforderungen
zurechtkommen, da es Lücken oder Fehler in den Anforderungen selbstständig
identifizieren und den Stakeholder zielgerichtet Lösungen anbieten kann.

In Entwicklungsprojekten für industrielle Softwaresysteme sind in der Regel verschiedene Abteilungen beteiligt, zum Beispiel Marketing, Vertrieb, Revision, IT-Anwendungsentwicklung, IT-Betrieb, externe Berater, Personalrat und Rechtsabteilung. Jede Organisationseinheit hat dabei eigene Vorstellungen und Zielsetzungen in Bezug auf das Softwaresystem. Unter Umständen gibt es innerhalb einzelner Abteilungen bereits schon Unterschiede. Diese Diversität wird häufig um nicht klar abgegrenzte Verantwortungsbereiche und mangelnde Fachkompetenz ergänzt. Ein vernachlässigtes Kommunikationsmanagement führt in solchen Softwareprojekten schnell zu unterschiedlichen Zielvorstellungen, dem Nicht-Treffen bzw. Verschieben von wichtigen Entscheidungen und dem Austragen von persönlichen Konflikten.

Je früher in einem Projekt die Gesamtkosten geschätzt werden, umso höher ist die Abweichung vom tatsächlichen Aufwand am Projektende. Mit zunehmendem Verlauf wird eine Schätzung der Gesamtkosten genauer, jedoch kann erst am Projektende präzise gesagt werden, wie hoch der Aufwand tatsächlich ist. Im Gegensatz zu Produktionsprozessen, bei denen der Verbrauch von Ressourcen und die Dauer der einzelnen Arbeitsschritte berechnet werden können, ist eine vergleichbare präzise Vorhersage bei Softwareprojekten in der Regel nicht möglich.

Beispiel: Wenn im Rahmen eines Projektes sehr großer Wert auf Qualitätssicherung gelegt wird, gehen die Aktivitäten der Qualitätssicherung zu Lasten der rechtzeitigen Fertigstellung. Wenn der Fokus auf die Projektkosten gelegt wird und dabei alle Termine einzuhalten sind, dann bleiben weniger Ressourcen für die Qualitätssicherung. Wenn aber ein Projekt in hoher Qualität punktgenau zu einem Termin ausgeliefert werden soll, dann wird der Kostenrahmen nicht zu halten sein.

In Softwareprojekten werden Unsicherheiten oftmals dadurch versucht zu kompensieren, dass ein möglichst genauer Plan bzw. ein möglichst detailliertes Modell aller möglichen Eventualitäten erstellt wird. Das bedeutet, dass entweder ein zu detaillierter Projektplanerstellt wird, der für das gesamte Projekt vorhersagen soll, welche Aktivitäten von wem mit welchem Aufwand durchgeführt werden sollen. Oder die fachlichen Anforderungen bzw. die Lösungsideen des Softwaresystems werden auf einer sehr detaillierten Ebene durchdacht. Die Gefahr der „Analysis Paralysis“ besteht darin, dass viele Ressourcen gebunden werden, die bei der Umsetzung einer ersten Softwareversion fehlen. Die zu Beginn aufwendig erstellten Analysemodelle veralten jedoch oft durch neu gewonnene Erkenntnisse bei der Umsetzung und Vorstellung der ersten Softwareversion.

.

• Planung: Aktivitäten vor dem Start eines Entwicklungsprojektes
• Entwicklung: Aktivitäten zwischen Start des Projektes und Inbetriebnahme des fertigen Systems
• Betrieb: Inbetriebnahme und Betreiben des Systems in der Zielumgebung
• Wartung: Wartung und Weiterentwicklung nach Inbetriebnahme
• Abschaltung: Aktivitäten mit dem Ziel das System aus dem Betrieb zu nehmen

Anhand der aktuellen Phase im Lebenszyklus kann sich das IT-Management einen Überblick über den aktuellen Zustand seiner Systemlandschaft verschaffen und darauf aufbauend die Personal-, Ressourcen- und Investitionsplanung aufstellen. Weiterhin lassen auf Basis der Bestimmung der aktuellen Phase im Lebenszyklus bestimmte Aktivitäten und Methoden des Software Engineerings ableiten.

• Bedarfsermittlung: Ermittlung des Bedarfs und der Anlässe für ein neues Softwaresystem
• Make-or-Buy-Entscheidung: Prüfen und Entscheiden, ob ein System gekauft oder neu gebaut werden soll
• Zeit- und Ressourcenplanung: Erstellung des ersten Projektplans inklusive konkretere Zeitund Ressourcenplanung.
• Auftragsvergabe: Vergabe des Auftrag, z. B. an externe Dienstleister oder interne IT-Abteilung

• Ablösung bestehender Altsysteme: IT-Systeme unterliegen einem Alterungsprozess und haben daher nur eine begrenzte Laufzeit. In Abhängigkeit der Laufzeit und der Anpassungshäufigkeit werden die Wartungsaufwände im Verhältnis zum erzielten Nutzen teurer, sodass es sinnvoller ist ein bestehendes System durch ein Neusystem zu ersetzen.
• Nachfrage der Fachabteilungen: Unternehmen erarbeiten sich Wettbewerbsvorteile durch den Einsatz von stark spezialisierten und eigens erstellten Softwaresystemen. Daher muss die Unternehmens-IT schnell auf neue fachliche Anforderungen reagieren und die Fachabteilungen gezielt mit geeigneten Systemen unterstützen. Falls fachliche Anforderungen nicht durch bestehende Systeme abgedeckt werden können, müssen neue Softwaresysteme bereitgestellt werden.
• Technologische Weiterentwicklung: Sich ändernde technische Rahmenbedingungen führen ebenfalls zu einem Bedarf an neuen Softwaresystemen.

Nachdem der Bedarf eines neuen Softwaresystems identifiziert worden ist, muss entschieden werden, ob bereits Softwarelösungen verfügbar sind, die den Bedarf abdecken (z. B. Content-Management-Systeme, E-Mail-Systeme, Textverarbeitung), ob es Standardprodukte gibt, die für unternehmensspezifische Anforderungen angepasst werden können (z. B. SAP Business Suite, Oracle E-Business Suite, IBM WebSphere) oder ob eine neue Software entwickelt werden muss. Diese Entscheidung wird Make-or-Buy-Entscheidung genannt. Je nachdem wie relevant die geforderte Software für die geschäftlichen Aktivitäten des Unternehmens ist und wie schwerwiegend die möglichen Folgen einer Fehlentscheidung sind, werden im Rahmen einer Make-or-Buy-Entscheidung Vorstudien, Testinstallationen oder erste Anwendungsprototypen erstellt und ausprobiert. Falls am Markt ein passendes System verfügbar ist und angeschafft wird, entfällt im Softwarelebenszyklus die Phase „Entwicklung“ und die Phase „Wartung“ wird deutlich weniger stark ausgeprägt.

Requirements Engineering, Spezifikation, Architektur, Implementierung, Qualitätssicherung. Sie sind Kernaktivitäten im Software Engineering und werden unter dem Begriff „Anwendungsentwicklung“ zusammengefasst.

Requirements Engineering: Fachliche Anforderungen an das System detaillieren und verfeinern Implementierung: Konstruktion des Systems durch Erzeugen des Quellcodes

• Bereitstellung der Ausführungsumgebung, das bedeutet, dass die für den Betrieb verantwortliche Abteilung eine entsprechende Infrastruktur, zum Beispiel in einem Rechenzentrum, zur Verfügung stellen muss.
• Integration, das bedeutet, dass das neue System an den von den Entwicklern vorgesehenen technischen Schnittstellen an bereits bestehende Systeme angeschlossen werden muss.
• Inbetriebnahme, das heißt nach dem Abschluss der Integration müssen alle technischen Schnittstellen estehender Systeme auf das neue System umgestellt sein. Für die Sicherstellung der Verfügbarkeit und der Sicherheit muss die neue Anwendung ebenfalls an technische Überwachungssysteme angeschlossen werden. Darüber hinaus muss die IT-Sicherheit die neue Anwendung mit in die Liste der zu überwachenden Anwendungen aufnehmen.

Sicherheit, Verfügbarkeit, Skalierbarkeit