Grundlagen der industriellen Softwaretechnik

• Ablösung bestehender Altsysteme durch neue Systeme
• Zusammenführung bzw. Vereinheitlichung von Anwendungen nach der Zusammenlegung von IT-Organisationen, zum Beispiel nach Zusammenschluss von Unternehmen oder im Rahmen der Konsolidierung einer gewachsenen Anwendungslandschaft
• Aufgeben von Geschäftsfeldern oder Auslagern von Aktivitäten aus dem Unternehmen

• Herauslösung aus Anwendungslandschaft: In einer IT-Anwendungslandschaft, deren Systeme untereinander über technische Schnittstellen miteinander verbunden sind, müssen alle Abhängigkeiten der abzuschaltenden Anwendung identifiziert und aufgelöst werden. Jede aktiv genutzte technische Schnittstelle des Altsystems muss entweder durch ein neues oder bereits bestehendes Alternativsystem abgedeckt werden.

• Migration von Daten: Werden in dem abzuschaltenden System Daten nicht nur verarbeitet, sondern auch gespeichert, müssen die Daten im Rahmen der Abschaltung migriert werden. Das bedeutet, die im Altsystem vorliegenden Daten müssen für die weitere Verwendung in ein anderes System übertragen werden.

• Verträge kündigen: Oft fallen für den Betrieb bestimmter Hardware oder Betriebssysteme anwendungs- und nutzerabhängige Lizenzkosten an. Entsprechende Verträge müssen gekündigt beziehungsweise dürfen nicht automatisch verlängert werden.

• Personal weiterqualifizieren: Im Rahmen der Abschaltung von Softwaresystemen muss das IT-Management auch dafür sorgen, dass Mitarbeiter, die für Betrieb und Wartung insbesondere von sehr langlebigen Anwendungen zuständig sind, auch nach der Abschaltung weiterbeschäftigt werden können. Insbesondere wenn sich mit der Abschaltung ein Technologiewandel vollzieht, müssen rechtzeitig Programme zur Weiterqualifizierung der Mitarbeiter konzipiert und umgesetzt werden.

• Liegt die Dokumentation nur unvollständig oder in einer veralteten Version vor, können Abhängigkeiten nur durch probeweises Abschalten identifiziert werden.
• Fehlendes Wissen zu alten Technologien, da die Wissensträger der alten Technologien bereits das Unternehmen verlassen haben.
• Bei der Migration von Daten darf es auch bei der Übertragung von mehreren Millionen Vertragsdaten – diese Anzahl ist bei Kranken- oder Lebensversicherungen durchaus üblich – keinen Fehler geben.

.

„Requirements Engineering (RE) ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel es ist, zu gewährleisten, dass
• alle relevanten Anforderungen bekannt sind und in erforderlichem Detaillierungsgrad verstanden wurden.
• alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationsvorschriften spezifiziert sind.
• die involvierten Stakeholder ausreichende Übereinstimmung über die bekannten Anforderungen erzielen.“

• Ermittlung von Anforderungen
• Dokumentation von Anforderungen
• Prüfen und Abstimmen von Anforderungen

Ziel der Aktivität „Ermittlung von Anforderungen“ ist die Identifikation der Anforderungen an das System, die zur Erreichung des Ziels benötigt werden. Dafür müssen die Anforderungen erkannt und in dem für die aktuelle Projektsituation erforderlichen Detaillierungsgrad verstanden werden. Die systematische „Ermittlung von Anforderungen“ unterteilt sich in die folgenden vier
Schritte:

• Systemkontext bestimmen: Es wird analysiert, welche Stakeholder und welche anderen Systeme direkte Abhängigkeiten zu dem zu erstellenden System haben. Diese müssen beim RE explizit mit berücksichtigt werden.
• Quellen für Anforderungen ermitteln: Typische Quellen für Anforderungen sind Stakeholder, Dokumente (z. B. Gesetze, Richtlinien) und andere Systeme (z. B. abzulösende Altsysteme oder Konkurrenzsysteme).
• Geeignete Ermittlungstechniken auswählen: Je nach Anforderungsquelle, Projektsituation und Art der Anforderungen muss eine geeignete Ermittlungstechnik oder eine Kombination aus verschiedenen Ermittlungstechniken ausgewählt werden (z. B. Befragungstechnik, Kreativitätstechnik, Beobachtungstechnik, Prototyping).
• Anforderungen unter Einsatz der Techniken ermitteln: Aus den bestimmten Quellen mit den gewählten Ermittlungstechniken werden Anforderungen in dem für die aktuelle Situation erforderlichen Detailgrad ermittelt.

Ziel der Aktivität „Dokumentation“ ist es, dafür zu sorgen, dass der aktuelle Erkenntnisstand für alle Stakeholder gesichert wird und sich jeder Beteiligte zu jeder Zeit einen Überblick verschaffen kann. Für die systematische „Dokumentation von Anforderungen“ lassen sich vier Schritte identifizieren:

Zweck und Zielgruppe der Dokumentation bestimmen: Die Dokumentation von Anforderungen unterstützt den Kommunikationsprozess im Softwareprojekt. Daher muss vor der Dokumentation gezielt Zweck und Zielgruppe bestimmt werden, für welche die Dokumentation erstellt wird.

Detailebene und Darstellungsart auswählen: In Abhängigkeit von Zweck und Zielgruppe wird die Detaillierungsebene und die Darstellungsart (z. B. Text, Grafiken, Softwaremodelle, Prototypen) festgelegt.

Anforderungen dokumentieren: Die ermittelten Anforderungen in einer für den Zweck und die Zielgruppe geeigneten Form dokumentieren.

Prüfen: Passt die Dokumentation noch zu Zweck und Zielgruppe?: Nach Abschluss der Dokumentation muss noch einmal kritisch reflektiert werden, ob die Art und Form noch zum Zweck und der Zielgruppe passt.

Ziel der Prüfung ist es, die Qualität der Menge der dokumentierten Anforderung hinsichtlich der Kriterien Inhalt, Dokumentation und Abgestimmtheit sicher zu stellen. Mit der Prüfung soll erreicht werden, dass die Anforderungen eine hohe Dokumentationsqualität haben und z.B. Missverständnisse durch Mehrdeutigkeiten vermieden werden und sich widersprechende oder konkurrierende Anforderungen identifiziert werden. Die Kernaktivität „Prüfen und Abstimmen“ lässt sich in vier Schritte unterteilen:

1.Prüfkriterien festlegen: Im Vorfeld der Prüfung ist festzulegen, nach welchen Kriterien genau geprüft werden soll. Damit wird der Fokus der Prüfung bestimmt, was insbesondere bei der Prüfung von umfangreichen Dokumenten notwendig ist, um den vorgegebenen Zeitplan einzuhalten.

Prüfprinzipien und Prüftechniken auswählen: Abhängig von den Prüfkriterien, der zur Verfügung stehenden Zeit und dem aktuellen Stand der Dokumentation werden zu berücksichtigende Prüfprinzipien und Prüftechniken ausgewählt (z. B. Review, Walkthrough, Erstellung von Softwareartefakten).

Prüfung durchführen und Ergebnisse dokumentieren: Während der Prüfung werden nur Ergebnisse dokumentiert. Die Fehlerbehebung erfolgt dann im Anschluss.

Abstimmen der Anforderungen / Konfliktmanagement: Werden bei der Prüfung Konflikte oder Widersprüche identifiziert, muss eine Abstimmung mit den relevanten Stakeholdern erfolgen, der sich gegebenenfalls Maßnahmen zur Konfliktauflösung anschließen.

Ermittelte fachliche Anforderungen werden bei der Spezifikation um technische Anforderungen erweitert und verfeinert. Das Resultat ist eine fachlich-technische Spezifikation, auf deren Basis zunächst das Systemdesign und anschließend die Implementierung des Systems erstellt wird. Außerdem werden auf Grundlage der Spezifikation Testfälle für die verschiedenen Teststufen erstellt, in denen das Softwaresystem auf Erfüllung der Anforderungen getestet wird.

Mit Spezifikation bezeichnen wir die Aktivitäten zur Dokumentation von detaillierten technischen Anforderungen. Dabei handelt es sich bezogen auf die Aktivitäten des Requirements Engineerings um eine Erweiterung und Detaillierung der Dokumentation von Anforderungen. Hinsichtlich Ermittlungstechniken oder Prüftechniken unterscheiden sich RE und Spezifikation nicht.

• Datenmodell: Das Datenmodell enthält die Geschäftsobjekte, die im System verarbeitet werden, sowie deren Beziehung untereinander.
• Fachfunktionen: fachliche Beschreibung der Aufgaben des Systems bzw. der spezifizierten Komponente

• Geschäftsregeln: Geschäftsregeln sind Regeln zu einem Geschäftsobjekt, die nicht verletzt werden dürfen.

• Eigenschaften, die zu Schnittstellen spezifiziert werden:

• Der Zweck der Schnittstelle auf einer fachlichen Ebene
• Das technische Protokoll beziehungsweise die technischen Regeln, nach denen das System mit seinem Umfeld kommuniziert
• Gegebenenfalls die Datenstruktur der Nachrichten, die an der Schnittstelle ausgetauscht werden
• Gegebenenfalls Aufbau und Verhalten der Benutzeroberfläche

• Qualitätseigenschaften des Systems: Qualitätseigenschaften eines Systems oder einer
Komponente werden prüfbar gemacht, beispielsweise durch messbare Metriken.
• Randbedingungen des Systems: technische und organisatorische Randbedingungen, die vom System eingehalten werden müssen, wie Verweise auf Richtlinien, Standards, Gesetze und Styleguides

Spezifikation von Benutzeroberflächen legt konkrete Vorgaben für folgende Aspekte fest:
• Inhalte und Aufbau von einzelnen Dialogmasken: Detaillierte Vorgabe zu Art, Größe, Position, Farbe und Inhalt von Elementen einer Bildschirmseite, z. B. von Eingabefeldern, Texten, Schaltflächen, Bildern
• Validierung von Daten: Spezifikation der Regeln, um Eingabefelder auf fachliche Plausibilität zu prüfen
• Dialogfluss: Spezifikation der Führung des Anwenders durch die Oberfläche in Abhängigkeit von eingebebenen Daten und Aktionen des Anwenders

Die konkret formulierten Qualitätseigenschaften haben einen maßgeblichen Einfluss auf die Architektur des zu entwickelnden Systems: Ob mit dem System nur fünf oder 500.000 Nutzer gleichzeitig arbeiten sollen, oder ob das System werktags von 09–16 Uhr oder an allen Kalendertagen 24 Stunden verfügbar sein muss – solche Qualitätseigenschaften beeinflussen die technische Umsetzung in der Regel stärker als die Erweiterung des Funktionsumfangs um eine weitere Fachfunktion.
Darüber hinaus muss insbesondere auf die Testbarkeit von Qualitätskriterien geachtet werden, da auf Basis der Spezifikation konkrete Testfälle erstellt werden. Daher müssen die Qualitätseigenschaften so spezifiziert werden, dass ihre Erfüllung im Rahmen von Tests nachgewiesen werden kann.

.

In der Literatur und praktischen Verwendung der Begriffe Architektur und Design hat sich bis heute keine allgemein anerkannte Definition oder Begriffsbildung durchgesetzt. Als Konsequenz wird insbesondere der Begriff „Architektur“ je nach Organisation, persönlicher Prägung und Vorliebe anders verwendet. So kann der Begriff der IT-Architektur – ähnlich dem klassischen Architekturbegriff – folgende Dinge zu bezeichnen:

• Den Prozess der Gestaltung von Softwaresystemen (und Teilsystemen) aller Art

• Die Titel einer IT-Architektur-Typologie, zum Beispiel „Client-Server-Architektur“

• Das Berufsfeld des IT-Architekten, also das Fachgebiet IT-Architektur

• Das Ergebnis, für das ein IT-Architekt verantwortlich ist, also die Menge der Artefakte die er erzeugt

• Die Bezeichnung für die Wissenschaft vom Gestalten von IT-Systemen, also die Lehre der IT-Architektur

Beginnend mit dem RE wird analysiert und anschließend spezifiziert, was vom System verlangt wird. Bei der Implementierung wird die Menge von Bedingungen und Vorgaben an ein konkretes System in ausführbaren Programmcode übersetzt. Zwischen RE/Spezifikation und Implementierung ist die Architektur angesiedelt. Der IT-Architekt muss die Bedürfnisse der Stakeholder analysieren und verstehen, gegeneinander abwägen und durch eine Menge von Entscheidungen und Gestaltungsaktivitäten eine Architekturdefinition entwickeln. Die Architekturdefinition stellt die Verbindung von Lösungsraum und Problemraum. Sie dient dem Entwicklerteam als
Vorlage und Rahmenwerk für die Aktivitäten zur Implementierung.

• Erfassen der Anforderungen und Interessen der Stakeholder: Zuerst analysiert der Architekt, was für die jeweiligen Stakeholder wichtig ist. Dabei muss er neben den spezifizierten fachlichen Anforderungen insbesondere auch die Stakeholder mit berücksichtigen, die an der Entwicklung und dem Betrieb des Systems beteiligt sind, sowie den Auftraggeber.

• Entwerfen einer Architektur, die diese Menge an Anforderungen erfüllt: Auf Basis der Menge der Anforderungen trifft der Architekt Entwurfsentscheidungen zur Erfüllung der Anforderungen. Das heißt, er erstellt eine erste Version der Architekturdefinition. Anschließend müssen die getroffenen Entscheidungen gegen die Anforderungen geprüft und bewertet werden.

Beschreiben und Dokumentieren der Architektur: Als dritte Kernaktivität müssen die getroffenen Entscheidungen in Form einer Architekturbeschreibung dokumentiert werden. Wie bei den Aktivitäten der Spezifikation, werden Architekturen unter Verwendung von Softwaremodellen technisch dokumentiert.

Das Ergebnis der Gestaltungsaktivitäten eines IT-Architekten ist die Architekturbeschreibung. Die eigentliche Architektur des Systems manifestiert sich jedoch erst während der Implementierung des Systems. Jedes System hat eine Architektur, auch wenn kein Softwarearchitekt eine Architekturbeschreibung erstellt hat. Architektur ist also systemimmanent.

• einfache Skizzen und Powerpoint-Grafiken
• strukturierte Softwaremodelle (z. B. UML)
• spezifische Architekturbeschreibungssprachen (ADLs)

.

Die eigentliche Erstellung des Softwaresystems erfolgt durch die Implementierung, das heißt dem Erzeugen (auch: Schreiben) von Programmcode. Auf Basis der dokumentierten fachlichen Anforderungen, der technischen Spezifikation und der Architekturdefinition wird eine Menge von Programmcode-Artefakten erstellt, die in ihrer Summe das lauffähige Softwaresystem ergeben. Die durch den Architekten erstellte Architekturbeschreibung macht Vorgaben an den Entwickler und legt einzuhaltende Rahmenbedingungen fest.

• Schreiben von Programmcode: Beim Schreiben von Programmcode erstellt der Programmierer strukturierten Text zur gezielten Lösung von spezifischen Problemen. Er erstellt zum Beispiel eine Datenstruktur, implementiert einen Algorithmus oder programmiert Regeln zur Bearbeitung von Daten.
• Bestehenden Programmcode wiederverwenden: Der Entwickler kann auf bereits programmierte Lösungen des Problems zurückgreifen und diese wiederverwenden. Bestehende Lösungen zu allgemeinen Problemen werden in sogenannten Bibliotheken (auch:Frameworks) den Entwicklern zur Wiederverwendung zur Verfügung gestellt.
• Programmcode automatisch generieren: Je nachdem wie detailliert eine Architekturbeschreibung ausgeprägt wurde, kann Programmcode direkt aus dem Modell erzeugt werden. Damit wird dem Entwickler die manuelle Erzeugung von fachlich trivialem Programmcode abgenommen.

• Unterstützung des Schreibens von Programmcode, z. B. durch Syntax-Highlighting, Erkennen und Anzeigen von Kompilierfehlern, automatische Vervollständigung, Navigation durch den Programmcode, einfaches Kompilieren und Ausführen des Programms zu Testzwecken
• Einbindung von Bibliotheken und Frameworks, z. B. durch einfache Import- und Navigationsfunktionen
• Generierung von Programmcode für triviale Aufgaben, z. B. mit grafischen GUIEditor und speziellen Dialogen zur Generierung von Standardcodefragmenten
• Unterstützung der Versionsverwaltung: Es müssen immer mehrere Entwickler gleichzeitig an dem gleichen Softwaresystem arbeiten können. Daher muss ermöglicht werden, dass jeder Entwickler immer über eine aktuelle Version aller Codefragmente verfügt, niemand die Arbeit seiner Kollegen aus Versehen überschreiben kann und im Fall des unbeabsichtigten Löschens jederzeit eine aktuelle Version wiederhergestellt werden kann.
• Erzeugen einer lauffähigen Version aus dem Programmcode (Kompilieren): Mit sogenannten Build-Systemen kann das Erstellen und Ausliefern komplexer Softwarepakete automatisiert werden. Darüber hinaus können mit dem Einsatz von Build-Systemen automatische Tests gestartet werden, welche die automatisch zusammengestellte Systemversion vor der Auslieferung auf Fehler testen.

• Welche Ausführungsumgebung steht später im Betrieb zur Verfügung?

• Welche Sprachen werden von den zur Verfügung stehenden Entwicklern beherrscht?

• Wie gliedert sich die Sprache in meine Anwendungslandschaft ein?

• Mit welchen Technologien/Sprachen sind die Anwendungen umgesetzt, mit denen ich das zu erstellende System später integrieren muss?

• Ist sichergestellt, dass das Wissen zu einer Technologie über den gesamten geplanten Lebenszyklus des Systems verfügbar ist?

• Gibt es bereits ausgereifte Frameworks und Bibliotheken für typische Probleme?

• Gibt es bereits Erfahrungen mit der Sprache im Einsatz von Produktivsystemen, die mit dem zu erstellenden System vergleichbar sind?

• Wie gut sind Tutorials, HowTos und Experten zu dieser Sprache verfügbar?

• Ist die Unterstützung der Sprache für zukünftige Systemplattformen gesichert?

.

„Softwarequalität ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen.“ Softwarequalität bezeichnet im weitesten Sinne eine Eigenschaft von Software. Unter dem Begriff Qualitätsmanagement (QM) werden hingegen alle organisierten Maßnahmen und Aktivitäten zusammengefasst, die der Verbesserung der Qualität von Produkten, Prozessen oder Leistungen jeglicher Art dienen.

Beim konstruktiven Qualitätsmanagement werden a priori (also vor der Erstellung) alle Qualitätseigenschaften für Produkte oder Prozesse definiert, um Fehler während der Softwareentwicklung zu vermeiden und die Qualität der erstellten Artefakte zu gewährleisten beziehungsweise zu erhöhen. Beim analytischen Qualitätsmanagement werden ex post (also nach der Erstellung) Maßnahmen zur Prüfung und Bewertung des aktuellen Qualitätsniveaus der Prüfobjekte durchgeführt, um Fehler systematisch aufzuspüren und ihre Ausmaße bestimmen zu können.

• Programmcode
• fachliche Anforderungen
• technische Spezifikationen
• Architekturbeschreibungen
• Testfälle

• Komponententest (auch: Modultest, Unittest): Während bzw. nach der Fertigstellung einer Softwarekomponente kann diese bereits auf Einhaltung von spezifizierten Vorgaben überprüft werden. Das isolierte Prüfen von einzelnen Softwarebestandteilen wird Komponententest genannt.

• Integrationstest: Während beziehungsweise nach der Integration wird in Integrationstests das Zusammenspiel von Gruppen von Komponenten getestet. Die Integrationstests prüfen, ob die Komponenten so zusammenarbeiten, wie es in der Spezifikation beschrieben wurde.

• Systemtest: Ziel des Systemtests ist die Überprüfung, ob das System als ganzes die spezifizierten Anforderungen erfüllt. Dabei werden neben den fachlichen Anforderungen auch die spezifizierten Qualitätseigenschaften getestet.

• Abnahmetest (auch: Akzeptanztest): Beim Abnahmetest wird geprüft, ob das System aus Kundensicht die vertraglich vereinbarten Leistungsmerkmale aufweist. Der Auftraggeber führt den Abnahmetest selber durch oder wird in der Durchführung mit einbezogen.

Im Anwendungsbetrieb wird dafür gesorgt, dass das System für die Nutzer verfügbar ist und gegen Ausfall- und Bedrohungsszenarien abgesichert wird. Der Anwendungsbetrieb hat an sich keine explizit konstruktive oder qualitätssichernde Funktion bei der Entwicklung eines Softwaresystems.

Bei der Übergabe der Software muss gewährleistet sein, dass sie nach Vorgaben und Richtlinien des Betriebs ausgeführt werden kann und die Software von der für den IT-Betrieb zuständigen Abteilung nach Entwicklung und Test in den Betrieb übernommen werden kann. Weiterhin werden mit Hilfe der Releaseplanung die Aktivitäten von Anwendungsentwicklung und Betrieb intern koordiniert.

• Um alle gewünschten Anpassungen und Änderungswünsche in wenigen Releases unterzubringen, müssen Änderungen an vielen Stellen der Anwendung gleichzeitig durchgeführt werden. Jedoch bergen große Anpassungen immer auch ein hohes Fehlerrisiko. Daher müssen auch umfassende Maßnahmen zur Qualitätssicherung durchgeführt werden, was wiederum weniger Zeit für den Einbau der Anpassungen lässt.

• Fachabteilungen sind unzufrieden mit der IT-Unterstützung, wichtige Änderungswünsche werden in der Regel erst nach Wochen oder Monaten umgesetzt. Insbesondere in Unternehmen, bei denen Informationssysteme direkt in der Wertschöpfungskette beteiligt sind, können durch eine zu langsame Reaktionszeit der IT Wettbewerbsnachteile entstehen.

• Eine lange Dauer zur Behebung von neu entdeckten Sicherheitslücken oder Fehlern in der Anwendung führt zu offenen Schwachstellen der IT-Infrastruktur und somit zu möglichen Angriffsszenarien.

Ein wichtiges Ziel vom IT-Service-Management ist die Erarbeitung und Bereitstellung eines standardisierten
Service-Portfolios, das gezielt auf typische Anforderungen an die IT-Services zugeschnitten ist, jedoch gleichzeitig einen standardisierten und effizienten Betrieb der IT-Infrastruktur ermöglicht. IT-Services sind etwa die Bereitstellung von Datennetzen, Serversystemen (Hardware), Betriebssystemen, Speichersystemen und Backuplösungen, also Dienstleistungen, die für die Entwicklung und den Betrieb von Softwaresystemen benötigt werden.