Motivation
We‘ve minimized the economic impact of the defects of the system via an advanced business process called ‘hoping nobody notices’. Dilbert, merican comic strip written and illustrated by Scott Adams
As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications. David Parnas, early pioneer of software engineering and professor of computer science
Der Nutzen von Anwendungssystemen zeigt sich nicht auf dem Papier, sondern erst in der Praxis, nämlich dann wenn Sie Teil eines betrieblichen Informationssystem werden. Um den Nutzen zu maximieren, müssen die richtigen Anwenundungssysteme ausgewählt oder entwickelt, an die Geschäftsprozesse angepasst (oder vice versa) und von den Mitarbeitenen genutzt werden. Welche Möglichkeiten zur Implementierung zur Verfügung stehen und was es zu beachten gilt ist Thema dieses Kapitels.
Lernergebnisse 🎯
Nach dieser Einheit
- verstehen Sie, weshalb Modelle für die Entwicklung und Anpassung von Anwendungssystemen notwendig sind,
- können Sie den Anwendungslebenszyklus beschreiben,
- kennen Sie erste Herausforderungen in der fachlichen Konzeption von Anwendungssystemen sowie Ansätze zum Umgang mit diesen,
- verstehen Sie Grundsätze der linearen Phasen-basierten sowie der agilen Methoden zur Entwicklung von Individualsoftware erläutern und
- können Sie den Auswahl- und Einführungsprozess von Standardsoftware beschreiben
Einleitung
Für viele Bereiche sind Anwendungen am Markt erhältlich, mit der die fachlichen Anforderungen vieler Unternehmen abgedeckt werden können — sogenannte Standardsoftware (Mertens et al., 2016).
Sind die Anforderungen des Unternehmens sehr spezifisch, so muss die Standardsoftware modifiziert bzw. erweitert werden.
Ist das nicht möglich, ist die Entwicklung eines unternehmensspezifischen Anwendungssystems erforderlich — sogenannte Individualsoftware (Mertens et al., 2016).
Einführung und Betrieb von Standardsoftware sind in der Regel mit weniger Risiken verbunden:
- Niedrigere und besser kalkulierbare Kosten und höhere Investitionssicherheit
- Möglichkeiten zur Evaluierung vor Einführung
- Höhere Qualität (Reife, Stabilität und Skalierbarkeit, Standardkonformität)
- Abbildung von Best-Practice Prozessen
Auf der anderen Seite kann Individualsoftware besser auf die Unternehmensbelange zugeschnitten werden. So können bspw. spezifische Prozesse, die eine Basis für Wettbewerbsvorteile darstellen, unterstützt werden.
Anwendungslebenszyklus
Der Lebenszyklus von betrieblichen Anwendungssystemen überspannt den Zeitraum zwischen der ursprünglichen Idee über die Entwicklung und Einführung, sowie die Wartung und evtl. Weiterentwicklung bis hin zur Ablösung (Krcmar, 2015).
Angesichts der relativ langen Lebensdauer von betrieblichen Anwendungen muss der Lebenszyklus systematisch gesteuert werden.
Der Anwendungslebenszyklus wird im Allgemeinen in sechs Phasen unterteilt: Entwicklung, Einführung, Wachstum,Sättigung/Reife, Rückgang und Abschaffung (Heinrich & Lehner, 2005).
Visualisierung
Krcmar (2015, S. 65–66) beschreibt die Phasen des Lebenszyklus wie folgt:
- Entwicklung: In der Phase der Entwicklung werden die Schritte der Ideenfindung und verwirklichung, beispielsweise im Rahmen eines Software-Entwicklungsprojekts oder -Auswahl und Beschaffungsprojekts, durchlaufen. Hier fallen während des Lebenszyklus die höchsten Systemkosten an.
- Einführung: Wird eine freiwillige Nutzung unterstellt, ist diese im Idealfall zunehmend. Die Nutzungsintensität wird auch vom Auftreten und Beseitigen von Fehlern während der Installationstests und zu Beginn des produktiven Betriebs bestimmt.
- Wachstum: In dieser Phase sind alle Tests abgeschlossen und alle während der Einführung aufgetretenen Fehler beseitigt. Alle Funktionen der Anwendung können produktiv genutzt werden. Es kommt idealerweise zu einem weiteren Anstieg der Nutzung, sofern es sich nicht um eine Anwendung mit beschränktem Benutzerkreis handelt.
- Sättigung/Reife: In dieser Phase erreicht die Nutzung ihren Höhepunkt. Bisherige Nutzer können keine weiteren Nutzungsmöglichkeiten entdecken und weitere Nutzer kommen nicht mehr hinzu. Ein Nutzungsrückgang kann dadurch verursacht werden, dass das System nicht mehr dem Stand der Technik entspricht, mit anderen, zeitlich nachgelagert eingeführten, Systemen konkurriert oder die Menge und Bedeutung der unterstützten Aufgaben zurückgeht.
- Rückgang: Der in der Phase Sättigung/Reife einsetzende Nutzungsrückgang setzt sich fort.
- Abschaffung: In dieser Phase wird die Entscheidung getroffen, zu welchem Zeitpunkt ein System abgeschafft oder durch ein neues System abgelöst wird. Über den Zeitpunkt der Nutzung hinaus kann das auslaufende System noch Umstellungskosten oder auch remanente Lizenzkosten verursachen.
Anforderungsmanagement
Vor der Auswahl einer Standardsoftware bzw. der Entwicklung einer Individualsoftware sowie deren Einführung eines Systems müssen die Anforderungen unternehmensspezifisch erhoben werden (Krcmar, 2015).
Informationssysteme sind soziotechnische Systeme. Deshalb müssen neben den technischen Anforderungen auch Anforderungen an die nicht-technischen Komponenten formuliert werden (insbesondere die zu gestaltenden Prozesse).
Das Anforderungsmanagement ist eine systematische Vorgehensweise, um alle relevanten Anforderungen zu ermitteln, zu analysieren, zu vereinbaren, zu spezifizieren, zu validieren, im Projekt zu verfolgen und gegebenenfalls zu ändern (Ebert, 2019).
Notwendigkeit
Anforderungsarten
Die Anforderungen an ein zu entwickelndes System können in funktionale und nichtfunktionale Anforderungen unterschieden werden.
- Funktionale Anforderungen
- Diese beschreiben das Verhalten und die Funktionen des Systems und geben an, was das System leisten soll (bspw. Funktionsumfang, UI/UX, Datenstrukturen, Integrationsmöglichkeiten).
- Nichtfunktionale Anforderungen
- Diese beschreiben, wie gut funktionale Anforderungen durch das System realisiert werden sollen (bspw. die Reaktionszeit, Verfügbarkeit, Sicherheit).
Visualisierung
Aktivitäten
Nach Ebert (2019) sind die Aktivitäten des Anforderungsmanagements:
- Anforderungsermittlung: Im Rahmen der Anforderungsermittlung werden die Anforderungsquellen, z. B. Stakeholder, identifiziert und die Anforderungen an das zu entwickelnde System erhoben.
- Anforderungsanalyse: Die ermittelten Anforderungen werden hinsichtlich ihrer Machbarkeit, Vollständigkeit oder Eindeutigkeit überprüft sowie konkretisiert und priorisiert. Das Ziel der Anforderungsanalyse ist die Beschreibung einer angestrebten Lösung, die die Anforderungen erfüllt.
- Anforderungsvereinbarung: Im Rahmen der Anforderungsvereinbarung werden Konflikte zwischen Stakeholdern in Bezug auf die Anforderungen identifiziert und gelöst.
- Spezifikation: Die abgestimmten Anforderungen werden in einem Anforderungsdokument, auch Anforderungsspezifikation genannt, festgehalten. Die Beschreibung des Systems kann zusätzlich, beispielsweise in Form von Use Cases, erfolgen.
- Validierung: Während der Validierung wird überprüft, ob die analysierten und spezifizierten Anforderungen den Stakeholderwünschen oder Marktbedürfnissen entsprechen.
- Änderungsmanagement: Das Änderungsmanagement hat die Aufgabe, mit Änderungen an Anforderungen so zu erheben, zu verwalten und zu priorisieren, dass die Projektlaufzeit sowie das Budget nicht überschritten werden und dass das Projekt insgesamt erfolgreich abgeschlossen werden kann.
Nach Abschluss der Validierung müssen alle Anforderungen an das System formuliert sein:
- Was das System können muss
- Was das System nicht können muss
- Wie das System sich verhalten soll
- Wie das System „aussehen“ soll (UI)
Spezifikation
Die Form der Beschreibung wird mit zunehmendem Detaillierungsgrad immer formaler bis hin zu einer detaillierten technischen Spezifikation (Modelle).
- Grobkonzept
- Semi-formale Beschreibung der fachlichen Anforderungen und Grenzen auf hohem Niveau
- Fachkonzept
- Detaillierte Ausformulierung der fachlichen Anforderungen inkl. formaler Modelle („Lastenheft“)
- Technisches Design
- Formaler Systementwurf mit allen systemseitig notwendigen Festlegungen und Eingrenzungen
Die Freiheitsgrade nehmen zunehmend ab. Im Idealfall kann ein am Prozess unbeteiligter Software-Entwickler auf Basis des technischen Designs das System ohne weitere Rückfragen erstellen.
Software-Entwicklung
Der Erfolg einer Anwendungsentwicklung hängt wesentlich davon ab, wie gut die einzelnen Schritte des Projektes geplant, wie gut Probleme vorhergesehen und mögliche Lösungen vorbereitet werden (Krcmar, 2015).
In der Praxis werden in der Software-Entwicklung zwei verschiedene Typen von Vorgehensmodellen verwendet:
- Lineare Phasenmodelle: Grundprinzip ist die Abgrenzung einzelner Phasen durch Meilensteine. Die Phasen werden sequenziell durchlaufen, Rücksprünge in vorangegangene Phasen sind nur dann vorgesehen, wenn festgestellt wird, dass gesteckte Ziele sonst nicht erreicht werden.
- Agile, iterative Vorgehensmodelle: Die Wiederholung von vorangegangenen Arbeitsschritten ist ausdrücklich vorgesehen.
Lineare Phasenmodelle
Die linearen Phasenmodelle zerlegen den Entwicklungsprozess in aufeinanderfolgende Spezifikationsschritte.
Die einzelnen Teilschritte schließen jeweils mit einem nachzuweisenden Ergebnis ab, das den Input für die nächste Phase bildet. Deshalb wird dieses Modelle auch oft als Wasserfall-Modell bezeichnet.
Falls Probleme auftauchen, für die Entscheidungen in vorigen Phasen ursächlich sind, muss in die Phase zurückgesprungen werden, in der diese getroffen wurden. Die Fehlerbeseitigung kann dann aufwändig sein.
Das Wasserfall-Modell stellt hohe, teilweise praxisferne Anforderungen, die in einer Vielzahl von Problemen resultieren (Mertens et al., 2016):
- Die Anforderungen an das neue System müssen vollständig vor Beginn der Implementierung vorliegen, Fehler werden oft erst spät erkannt
- Üblicherweise ist es kaum möglich, Anforderungen ex ante vollständig und korrekt zu formulieren
- Manche Anforderungen ergeben sich erst während der Nutzung des neuen Systems
- Zwischen der Spezifikation der Anforderung und der Produktivsetzung des Systems können mehrere Monate bis Jahre vergehen, in einem VUCA Umfeld ändern sich in dieser Zeit die Anforderungen fast zwangsläufig
Das Wasserfall-Modell kommt in seiner Reinform in der Praxis üblicherweise nicht vor. Statt dessen werden oft zyklische Phasenmodelle verwendet, die aus mehreren sich überlappenden Wasserfall-Modellen bestehen und Rücksprünge in Vorphasen vorsehen (Krcmar, 2015).
Visualisierung
Agile, iterative Ansätze
Agile Ansätze umfassen wiederholt ablaufende Aktivitäten, an deren Ende jeweils ein messbares Teilergebnis, d. h. eine teilfertige und nutzbare Version des zu erstellenden Systems, als Grundlage für nachfolgende Iterationen steht (Mertens et al., 2016).
- Als Basis der Umsetzung dient in der Regel eine fachliche Anforderungsdefinition („User Story“), die in einzelne logisch zusammengehörende Arbeitspakete unterteilt wird.
- Die Kommunikation zwischen den Entwicklern und mit den späteren Nutzern der Software ist ein wichtiges Element. Wenn möglich, sollen die teilfertigen Versionen schnell eingeführt und schrittweise ergänzt werden.
- Ein Beispiel für ein solchen Ansatz ist SCRUM.
Bei dem SCRUM-Vorgehensmodell werden Arbeitspakete in sog. „Sprints“, d. h. vierwöchigen Implementierungsphasen, entwickelt. Im Anschluss werden die Ergebnisse direkt vom Nutzer getestet.
Selbstorganisation, Transparenz, Kunden-Fokus, Flexibilität und kontinuierliche Verbesserung sind wesentliche Werte dieser Vorgehensmodelle.
Visualisierung
Software-Einführung
Projekte zum Einführen von Standardsoftware dauern zumeist mehrere Monate. Die Einführungskosten, insbesondere Personalkosten, übersteigen dabei meistens deutlich die Kosten für die Software (insbesondere Lizenzkosten) (Mertens et al., 2016).
Auch bei der Einführung von Standardsoftware ist ein erhebliches fachliches Verständnis für die zu unterstützenden betrieblichen Funktionen und Prozesse notwendig.
Projekte zum Einführen von Standardsoftware laufen vergleichbar der Individualentwicklung in Phasen ab.
Analog zur Entwicklung von Individualsoftware existieren verschiedene phasenorientierte Vorgehensmodelle. Allen gemein sind drei Grundphasen: die Auswahl, die Einführung sowie der Betrieb der Software.
Phasenmodell
Bei der Anpassung unterscheidet man zwischen Customizing und Parametrisierung. Im Rahmen des Customizing werden Eigenschaften der Software in der Regel per Programmierung angepasst, im Rahmen der Parametrisierung werden vorhandene Einstellungsmöglichkeiten des Systems zur Anpassung verwendet.
Produktauswahl
Die Auswahl einer Standardsoftware lässt sich in vier Phasen gliedern.
- Identifikation
- Zielsetzung: Den Markt verstehen und mögliche Lösungen identifizieren
- Wichtige Aktivitäten:
- Anforderungen in einem Kriterienkatalog erfassen
- Liste potenzieller Anbieter erstellen (Long List)
- Informationen anfordern (Request for Information, RfI)
- Eingrenzung
- Zielsetzung: Detailliertes Verständnis der Fähigkeiten der Lösungen und Anbieter gewinnen
- Wichtige Aktivitäten:
- Bewertung der Antworten der Anbieter auf die RfI
- Erweiterung des Kriterienkatalogs und Entwicklung von Use Cases
- Erstellung der Short List
- Bewertung
- Zielsetzung: Das optimale System und den optimalen Anbieter ermitteln
- Wichtige Aktivitäten:
- Anforderung kommerzieller Angebote der Short-List (Request for Proposal, RfP)
- Durchführung von Workshops zur Bewertung der Lösungen anhand der Use Cases
- Entscheidung
- Zielsetzung: Auswahl des Anbieters und Vertragsverhandlung
- Wichtige Aktivitäten:
- Analyse der kommerziellen Angebote (Favorit und Herausforderer)
- Abschluss der Verhandlungen (finales Angebot)
- Entscheidung treffen und abstimmen
Auswahlkriterien
Im Rahmen der Softwareauswahl sollten sowohl das Anwendungssystem als auch der Anbieter und die kommerziellen Rahmenbedingungen evaluiert werden.
Wichtige Eigenschaften des Anbieters sind unter anderem:
- Branchen-Kenntnis
- Release-Strategie
- Verfügbarkeit und Support-Strukturen
- Ausfallrisiko
- Implementierungsansatz
- Partner-Ökosystem
- Erfolgsbilanz/Referenzen
Wichtige kommerzielle Rahmenbedingungen sind:
- Implementierungskosten
- Investitionskosten
- Betriebskosten (inkl. Langzeitprojektion)
Lizenzmodelle
Die in der Praxis vorkommenden Lizenzmodelle für kommerzielle Anwendungssysteme unterscheiden sich hauptsächlich in den Bezugsgrößen, die für die Ermittlung der Lizenzkosten herangezogen werden (Krcmar, 2015):
- Nutzerbezogene Modelle—Bezugsgröße ist in der Regel die Anzahl der Nutzer (Lizenzkosten pro Nutzer)
- Wertbezogene Modelle—Bezugsgröße können Personalbestand, Herstellkosten oder verkaufte Produkte sein (z.B. Umsatzbeteiligung in einem Webshop)
- Zeitbezogene Modelle—Bezugsgröße ist die Dauer der Nutzung (Subskription)
- Infrastrukturbezogene Modelle—Bezugsgröße ist das Ausmaß der Nutzung der Infrastruktur (bspw. IaaS nach Prozessor- oder Speichernutzung, Lizenzkosten pro Gerät)
Übungen ✏️
Konzept-Speed-Dating
In dieser Übung vertiefen Sie zentrale Konzepte aus Softwareentwicklung und Anforderungsmanagement spielerisch.
Bilden Sie Paare und erklären Sie sich rundenweise untenstehende Begriffspaare. Nach der Erläuterung diskutieren Sie gemeinsam, vergleichen Vor- und Nachteile oder Einsatzszenarien.
- Standard- vs. Individualsoftware
- Funktionale vs. nicht-funktionale Anforderungen
- Wasserfall vs. Agile (SCRUM)
- Einführung-Phase vs Sättigung-/Reife-Phase
01:30
Mini-Fallstudie: HNU Campus-App
Phase 1: Anforderungsmanagement
Die HNU plant eine neue Campus-App. Ihre Aufgabe ist es, die Anforderungen für die App zu erfassen.
Bilden Sie Gruppen und arbeiten Sie an folgenden Aufgaben:
- Stakeholder identifizieren (Wer ist betroffen?)
- Anforderungen sammeln (je 5 funktionale und nicht-funktionale Anforderungen)
- Priorisieren (verwenden Sie die MoSCoW-Methode — Must / Should / Could / Won’t)
- Zielkonflikte erkennen (bspw. Datenschutz vs. Personalisierung)
10:00
Denken Sie zunächst für sich nach (ca. 10 Minuten) und sammeln Sie Ideen zu Stakeholdern und Anforderungen. Danach diskutieren Sie Ihre Erkenntnisse in der Gruppe und
- Dokumentieren die wesentlichen Anforderungen übersichtlich
- Diskutieren Sie gemeinsam, welche Anforderungen besonders kritisch sind
Wir werden sehen: Das Erfassen und Priorisieren von Anforderungen ist die Grundlage für alle weiteren Phasen.
Phase 2: Anforderungsspezifikation
Anforderungen werden iterativ auf drei Ebenen spezifiziert:
- Grobe Anforderung: Was soll grundsätzlich erreicht werden?
- Fachliche Anforderung: Was soll die App konkret leisten?
- Technische Anforderung: Wie wird es technisch umgesetzt?
Aufgabe:
- Führen Sie die Strukturierung für eine funktionale Anforderung durch (Einzelarbeit)
- Diskutieren Sie anschließend Ihre Spezifikation in der Gruppe:
- Was fiel leicht, womit hatten Sie Probleme?
- Welche Ebene ist für welche Stakeholder besonders relevant?
10:00
| Ebene | Leitfrage | Beispiel |
|---|---|---|
| Grob-Konzept | Was soll erreicht werden? | Studierende sollen ihren Stundenplan einsehen können |
| Fach-Konzept | Was soll die App konkret leisten? | Anzeige persönlicher Stundenplan inkl. Änderungen aus Moodle |
| Technisches Design | Wie wird es umgesetzt? | REST-API, täglicher Datenabgleich, Frontend React |
Wir werden sehen: Drei-Ebenen-Spezifikationen helfen, Anforderungen nach und nach präzise zu beschreiben und Missverständnisse zu vermeiden.
Phase 3: Make-or-Buy-Entscheidung
Für die Campus-App müssen Sie entscheiden: Eigenentwicklung oder Standardsoftware?
Bilden Sie Gruppen und bearbeiten Sie folgende Aufgaben:
- Erstellen Sie eine Bewertungsmatrix mit den wesentlichen Kriterien.
- Diskutieren Sie Vor- und Nachteile der Optionen und treffen Sie eine Entscheidung.
- Falls Sie sich für „Buy“ entscheiden: Überlegen Sie ein für Hochschule und Anbieter sinnvolles Lizenzmodell (nutzer-/zeit-/infrastrukturbezogen)
15:00
| Kriterium | Gewichtung | Eigenentwicklung | Standardsoftware |
|---|---|---|---|
| Kosten | Hoch | Hoch | Niedrig |
| Zeit | Hoch | Lang | Kurz |
| Individualität | Mittel | Hoch | Mittel |
| Wartung | Mittel | Eigenverantwortung | Anbieter |
| Risiko | Hoch | Hoch | Mittel |
Begründung: Standardsoftware ist günstiger und schneller verfügbar, aber weniger individuell. Eigenentwicklung bietet maximale Anpassung, ist aber teuer und riskant.
Wir werden sehen: Eine strukturierte Bewertungsmatrix macht Entscheidungen transparent und nachvollziehbar.
Phase 4a: Make — Vorgehensmodell wählen
Sie haben sich für eine Individualsoftware entschieden. Für die Implementierung müssen Sie ein Vorgehensmodell auswählen.
- Bilden Sie zwei Fraktionen: Wasserfall-Verfechter und Agile-Verfechter
- Diskutieren Sie, welches Modell besser für die Campus-App passt.
- Definieren Sie ein MVP (Minimum Viable Product) für einen agilen Start:
- Welche Funktionen müssen im ersten Release enthalten sein?
- Welche Funktionen können später ergänzt werden?
- Diskutieren Sie, wie das MVP Risiken reduziert und welche Stakeholder davon profitieren
10:00
Wir werden sehen: Vorgehensmodelle beeinflussen Entwicklungsstrategie, Zeitplan und Stakeholder-Zufriedenheit.
Phase 4b: Buy — Auswahl & Einführung
Sie haben sich für eine Standardsoftware entschieden. Planen Sie nun den Auswahlprozess entlang des 4-Phasen-Modells.
- Gehen Sie jede Phase nacheinander durch (Long List → RfI → Short List → RfP/Entscheidung).
- Überlegen Sie selbst die Leitfragen, die Sie in jeder Phase beantworten müssen.
- Diskutieren Sie in der Gruppe:
- Welche Risiken könnten auftreten?
- Welche Zielkonflikte müssen berücksichtigt werden?
- Welche Anforderungsebene (Grob / Fachlich / Technisch) ist für die Auswahl am wichtigsten?
- Reflektieren Sie, wie klar spezifizierte Anforderungen den Auswahlprozess erleichtern.
15:00
Wir werden sehen: Die Qualität der Anforderungsspezifikation bestimmt, wie effektiv die Auswahl und Einführung einer Standardsoftware verläuft.
Lernkontrolle 🧐
- Was sind Herausforderungen in der Anforderungserhebung?
- Worin unterscheiden sich funktionale und nicht-funktionale Anforderungen?
- Was sind Vor- und Nachteile linearer Phasenmodelle?
- Worin unterscheiden sich agile Vorgehensmodelle?
- Welche Ähnlichkeiten erkennen Sie zwischen agilen Vorgehensmodellen in der Software-Entwicklung und Design Thinking?
- Welche Kriterien sollten bei der Auswahl eines Standard-Anwendungssystems berücksichtigt werden?
- Welche Kosten müssen bei der Entscheidung zur Implementierung von Anwendungssystemen berücksichtigt werden?