Softwaretechnik / Software Engineering

Was ist Software?

Software ist eine Sammelbezeichnung für Computerprogramme. Nach IEEE umfasst Software neben Programmen, Abläufen und Regeln auch Dokumentation und Daten. Softwaresysteme sind Systeme, dessen Komponenten aus Software bestehen.

Softwaretechnik

Unter Softwaretechnik versteht man die Entwicklung von Software, unter Berücksichtigung von Prinzipien, Methoden, Konzepten und Werkzeugen, so dass effiziente und qualitativ hochwertige Software-Systeme bereitgestellt werden können. Neben der Entwicklung neuer Software zählt auch das Betreiben bzw. das Warten und die Pflege der Anwendung hinzu.

Häufig wird der Begriff Softwaretechnik mit Softwareentwicklung gleichgestellt. Allerdings handelt es sich bei der Softwareentwicklung um die Tätigkeiten, die innerhalb der Softwaretechnik ausgeführt werden. Neben der Softwareentwicklung gibt es weiter Teildisziplinen in der Software-Technik. Das Software-Management ist für die Planung, Organisation und Kontrolle des Entwicklungsprozesses zuständig. Unter der Software-Qualitätssicherung verstehen wir Maßnahmen zur Einhaltung der geforderten Qualität. Diese unterteilt man in interne und externe Qualitätsfaktoren. Externe Faktoren fördern die Qualität auf Benutzerebene, interne Faktoren auf Entwicklerebene.

Qualitativ hochwertige Software:

arbeitet korrekt und zuverlässig,
reagiert auf Fehlereingaben,
stellt eine benutzerfreundliche Oberfläche bereit,
ist gut kommentiert und dokumentiert,
sollte möglichst plattformunabhängig sein,
und somit anpassbar und erweiterbar

Weitere Teildisziplinen sind die Software-Wartung und die Software-Pflege welche die Fehlerbeseitigung und der Weiterentwicklung aufgrund neuer Anforderungen abdecken.

Softwarefehler

„Ein Programmfehler oder Softwarefehler oder Software-Anomalie, häufig auch Bug genannt, bezeichnet im Allgemeinen ein Fehlverhalten von Computerprogrammen. Dies tritt auf, wenn der Programmierer eine bestimmte Festlegung der Spezifikation nicht oder falsch umgesetzt hat, oder wenn die Laufzeitumgebung fehlerhaft bzw. anders als erwartet arbeitet. Weiterhin können auch Unvollständigkeit, Ungenauigkeit oder Mehrdeutigkeiten in der Spezifikation des Programms zu „Fehlern“ führen.“

Weitere Ursachen sind die ständig zunehmende Komplexität der zu lösenden Aufgabe, welche durch immer komplexere Hardware, erweiterten Programmiersprachen und Programmierumgebungen und die Entwicklung für unterschiedliche Plattformen zustande kommt. Dadurch steigt die Schwierigkeit und Fehleranfälligkeit und somit auch der Programmieraufwand überproportional.

Heut zu Tage werden Fehler bzw. die Fehlerdichte bei der Erstellung von Software mit eingeplant. Fehlerfreie Software zu erstellen ist aus betriebswirtschaftlicher und technischer Sicht nahe zu unmöglich. Die Software-Produktivität bzw. der Programmieraufwand wird in "Lines of code" angegeben, was allerdings ein umstrittener Maßstab für die Angabe der Produktivität ist. Eine Alternative ist das Function-Point Verfahren. Die Fehlerdichte, also die Anzahl an Fehler pro 1000 Linien Code wird deshalb versucht möglichst gering zu halten. Der "Coverity Scan Report" nimmt sowohl kommerzielle als auch Open-Source-Projekte hinsichtlich der Fehlerdichte unter die Lupe. Aus den jährlichen Berichten geht hervor, dass die Fehlerdichte zwischen 0,5 und 1 beträgt. Windows 10 zum Beispiel weißt 50 Millionen Lines of code auf, das sind bei einer Fehlerdichte von 0,5 immerhin 25000 Fehler.

Softwaretechniker / Software Engineer

Softwareentwickler/Softwaretechniker beschäftigen sich mit der Entwicklung und Optimierung von Software. Neben guten Programmierkenntnissen, einem guten Verständnis für Datenstrukturen und Algorithmen und der Beherrschung einer oder mehrere Programmiersprachen gehören auch Fähigkeiten in der Kommunikation auf verschiedenen Abstraktionsebenen und die Arbeitsplanung und -koordination zu den Fähigkeiten eines Softwaretechnikers.

Aufgrund stetiger Weiterentwicklung der Technik und zunehmender Komplexität, steigt der Programmieraufwand und somit auch die Schwierigkeit und Fehleranfälligkeit der Software. Auch die Anforderungen des Kunden werden immer spezifischer.

Diese Einflussfaktoren führen zu einer hochgradigen Spezialisierung der Softwaretechnik. Eine Spezialisierung ist zum Beispiel App-Entwicklung für unterschiedliche Zielplattformen.

Ethische Regeln des Software Entwicklers

„Softwareentwickler verändern die Welt“. Um verantwortungsbewusst zu handeln, sollten sie über die umfassenderen Auswirkungen ihrer Arbeit nachdenken und das Gemeinwohl konsequent unterstützen. Der ACM-Kodex für Ethik und berufliches Verhalten drückt das Gewissen des Berufs aus.

Der Ausschuss für Berufsethik (The Committee on Professional Ethics - COPE) ist dafür verantwortlich, das ethische Verhalten von Computerfachleuten zu fördern, indem er den Ethikkodex veröffentlicht und Interpretationen des Kodex anbietet.

Öffentlichkeit: Software-Entwickler sollen durchweg in Übereinstimmung mit dem öffentlichen Interesse handeln.
Kunde und Arbeitgeber: Software-Entwickler sollen im Interesse ihrer Kunden und ihres Arbeitgebers handeln. Verwenden Sie nicht wissentlich Software, die illegal oder unethisch erworben oder aufbewahrt wird
Produkt: Software-Entwickler sollen sicherstellen, dass das Endprodukt höchstmöglichste professionelle Standards einhält. Streben Sie nach hoher Qualität, akzeptablen Kosten und einem angemessenen Zeitplan, um sicherzustellen, dass signifikante Kompromisse für den Arbeitgeber und den Kunden klar sind und von diesem akzeptiert werden
Beurteilung: Integrität und Unabhängigkeit bei der Beurteilung eines Sachverhalts
Management: Manager und Führungskräfte der Softwareentwicklung müssen sich einem ethischen Ansatz für das Management der Softwareentwicklung und -wartung anschließen und diesen fördern. Gewährleistung eines guten Managements für jedes Projekt, an dem sie arbeiten, einschließlich wirksamer Verfahren zur Förderung der Qualität und Risikominderung
Beruf: Softwareentwickler fördern die Integrität und das Ansehen des Berufs im Einklang mit dem öffentlichen Interesse. Zum Beispiel durch Förderung des öffentlichen Wissens über Softwareentwicklung.
Kollegen: Unterstützendes und faires Verhalten gegenüber der eigenen Kollegen.
Selbst: Lebenslanger Lernprozess als Software-Entwickler

Vorgehensmodelle

Aufgrund stetig zunehmender Komplexität der Software gewinnt das Thema Vorgehensmodelle in der Softwareentwicklung zunehmend an Bedeutung.

Zu Beginn der Zeit der Softwareentwicklung wurden Programme hauptsächlich nach dem "Code and Fix" Prinzip erstellt. Diese Variante kennt sicherlich jeder Softwareentwickler. Man beginnt mit der Programmierung ohne einen vorherigen Plan aufgestellt zu haben. Das führt schnell zu einem lauffähigen Programm, ohne komplexe Tests. Durch die fehlende Planung kann leider keine Angabe über die Qualität der Software gemacht werden. Zudem ist das Arbeiten im Team am gemeinsamen Projekt unmöglich. Deshalb wurden schon sehr früh Modelle definiert, die ein Projekt planbar machen und somit die Software-Qualität gewährleisten - Vorgehensmodelle.

Vorgehensmodelle beschreiben auf einem abstrakten Niveau eine Abfolge von Phasen bzw. von einzelnen Aktivitäten. Diese Phasen stehen in Zusammenhang miteinander. Eine Phase kann zum Beispiel erst beginnen, wenn die Phase zuvor abgeschlossen ist. Ein Vorgehensmodell stellt also die Arbeitsschritte der Softwareentwicklung in einzelnen Phasen dar und beschreibt somit den Software-Entwicklungsprozess. Daraus entsteht eine logische und zeitliche Ordnung der Phasen.

Durch Vorgehensmodelle kann also eine erfolgreiche Durchführung von Softwareentwicklungen geplant werden. Das Ziel hierbei ist es, die zur Verfügung stehende Zeit zur Fertigstellung und die Vorgabe der Kosten und Qualität der Software einzuhalten.

Im Laufe der Zeit wurden immer mehr Vorgehensmodelle definiert und veröffentlicht, die spezifische Probleme lösen sollen. Es gibt allerdings auch eine Reihe klassischer Vorgehensmodelle, die im Folgenden näher erläutert werden.

Wasserfallmodell

„dokumentengetriebenes“ Modell

Eines der ersten und bekanntesten Vorgehensmodelle ist das Wasserfallmodell. Die einzelnen Phasen die das Wassermodell beschreibt sind stufenförmig angeordnet. Die Phasen des Wasserfallmodells werden dabei von oben nach unten abgearbeitet. Erst wenn eine Phase abgeschlossen ist, kann mit der nächsten begonnen werden. Die Bearbeitung dieser Phase ist nämlich abhängig von den Ergebnissen der vorherigen Phase. Die Ergebnisse werden der nachfolgenden Phase als Dokument bereitgestellt, weshalb das Wasserfallmodell zu den „dokumentengetriebenen“ Modellen zählt.

V-Modell 97 und V-Modell XT

Validierungs- und Verifizierungsmodell

Das V-Modell (97) wurde im Jahr 1970 als eine Art Erweiterung des Wasserfallmodells vorgestellt. Die Phasen bei diesem Modell sind v-förmig angeordnet. Der linke Arm beinhaltet die Phasen zur Herstellung der Software (ähnlich wie beim Wasserfallmodell), im rechten Arm liegen die zugehörigen Maßnahmen zur Qualitätssicherung.

Im Regelfall bestehen die Maßnahmen zur Qualitätssicherung darin, bestimmte Tests (Unit Tests, Integrationstests, Systemtests, Komponententests usw.) durchzuführen. Mit Hilfe des V-Modells kann also zu jeder Entwicklungsphase kontrolliert werden, ob Entwicklungsfortschritt und Softwarespezifikation übereinstimmen. Das V-Modell 97 ist in 4 Submodelle gegliedert:

Systemerstellung (SE)
Qualitätssicherung (OS)
Konfigurationsmanagement (KM) und
Projektmanagement (PM)

Das V-Modell 97 wird seit 1997 nicht mehr weiterentwickelt, weshalb es heut zu Tage auch nicht mehr den Entwicklungsstandards entspricht. Deshalb wurde im Laufe der Zeit ein weiterentwickeltes Modell publiziert – das V-Modell XT. Im Gegensatz zum V-Modell 97 weißt das V-Modell XT keine Submodelle auf, sondern basiert auf aufeinander aufbauenden Vorgehensbausteinen.

Das XT-Modell wurde unter Berücksichtigung neuer Technologie-Standards und aktueller Normen entwickelt. Maßgebliche Änderungen zum V-Modell 97 sind Projektdurchführungsstrategien, Entscheidungspunkte und ein angepasstes Tailoring-Konzept.

Tailoring bedeutet ins Deutsche übersetzt so viel wie "schneiden" oder "anpassen". Es handelt sich also um projektspezifische Anpassungen, welche Projektaktivitäten, Produktauswahlen und das Weglassen von nicht mehr benötigten Aspekten betreffen. Durch das Tailoring werden Projektmerkmale und Projekteigenschaften bestimmt und somit eine Projektdurchführungsstrategie zur zeitlichen Anordnung von Entscheidungspunkten geliefert.

V-Modell 97, V-Modell XT Softwareentwicklung

Spiralmodell

Risikoorientiertes Metamodell

Beim Spiralmodell handelt es sich um ein risikoorientiertes Metamodell, da es mit anderen Vorgehensmodellen kombiniert werden kann und als oberstes Ziel die Risikominimierung vorgenommen wird. Die einzelnen Schritte bzw. Phasen, die durch das Spiralmodell abgearbeitet werden, sind spiralförmig angeordnet und werden mehrmals durchlaufen. In jedem Durchlauf werden Ergebnisse erzielt, die zur Abarbeitung für den nächsten Durchlauf dienen. Jede Spirale stellt einen iterativen Zyklus dar, da dieselben Phasen wiederholt durchlaufen werden. Dieser Zyklus durchläuft beim Spiralmodell 4 Phasen - Planung und Zielbestimmung, Bewertung der Risiken, Durchführung der Arbeitsschritte und Erstellung von Prototypen, Überprüfung der Ziele und Planung bis hin zur Produktauslieferung.

Agile Softwareentwicklung

Inkrementelle (iterative) Software Entwicklung

Die zuvor betrachteten klassischen schwergewichtigen Vorgehensmodelle, wie das Wasserfallmodell und das V-Modell, zeichnen sich durch einen großen Umfang der Spezifikationen aus. Das führt zu einer sehr formalen Vorgehensweise. Schwergewichtige Vorgehensmodelle werden verwendet, wenn die Projektdetails zu Beginn größtenteils bekannt sind.

In der agilen Softwareentwicklung kommen leichtgewichtige Vorgehensmodelle zum Einsatz. Diese verlangen keine ausführliche Spezifikation des Projekts und versprechen ein agiles und flexibles vorgehen.

Im Laufe der Zeit hat sich die inkrementell-iterative Software Entwicklung durchgesetzt. Die Grundidee dieser Methode ist es, das Projekt in mehreren geplanten und kontrollierten Iterationsschritten zu entwickeln. In jedem Iterationsschritt werden wiederum grundlegende Projekttätigkeiten wie Analyse, Entwurf, Codierung und Tests durchgeführt. Der Begriff „inkrementelle Softwareentwicklung“ kommt daher, da nach jedem Iterationsschritt ein neues Inkrement vorliegt. Ein Inkrement bedeutet ins Deutsche übersetzt „vergrößern“. In jedem Iterationsschritt wird die Software um neue Funktionenund Anforderungen erweitert. Zugleich werden Tests und Fehlerbehebungen durchgeführt.

Agile "leichtgewichtige" Softwareentwicklung ist anpassungsfähig und Menschen-orientiert. Klassische "schwergewichtige" Softwareentwicklung ist vorausschauend und Prozess-orientiert

Die Phasen der Softwareentwicklung

Machbarkeitsstudie (feasibility study)

Die erste Phase die bei der Softwareentwicklung durchlaufen wird ist die Machbarkeitsstudie. Dort wird entschieden, ob ein Projekt durchgeführt werden kann oder nicht. Gezielter wird ein Projekt auf die fachliche, ökonomische und personelle Durchführbarkeit geprüft. Also ob genügend Mittel und Mitarbeiter für das Projekt zur Verfügung stehen, und ob diese die benötigte fachliche Kompetenz aufweisen. Deshalb ist eine grobe Analyse des zu lösenden Problems notwendig. Hierzu gehört ebenso eine Aufwandschätzung. Welche Ausgaben müssen für die Fertigstellung des Projekts getätigt werden? Wie ist der mögliche Ertrag? Also kann überhaupt ein Gewinn erzielt werden?

Bei der Machbarkeitsstudie sollte man zwischen der Produktentwicklung für einen konkreten Kunden und der Produktentwicklung für den freien Markt unterscheiden. Bei der Entwicklung von Kundenprojekten müssen lediglich die Bedürfnisse und Wünsche des Kunden abgedeckt werden. Möchte man mit einem Produkt die breite Masse ansprechen, zum Beispiel mit einer App, muss die Entwicklung des Produkts genauer geplant werden um zu klären ob es überhaupt einen Bedarf dafür gibt. Hinzu kommen schließlich Trendstudien, Marktanalysen, Forschungsergebnisse und Kundenanfragen. Hier werden Fragen gestellt wie: Ist das Produkt erfolgsversprechend? Gibt es Konkurrenzprodukte auf dem Markt? Gibt es bereits Software bzw. Produkte die adaptiert werden kann? Gibt es Forschungsergebnisse die verwendet werden können? Zudem können potentielle Kunden hinsichtlich ihrer Wünsche und Bedürfnisse zum neuen Produkt befragt werden. Diese können je nach Befragungsergebnisse in das Projekt mit aufgenommen werden.

Die Ergebnisse aus der Machbarkeitsstudie werden im Regelfall in einem sogenannten Lastenheft dokumentiert. Des Weiteren sollte dem Kunden nach einer Machbarkeitsstudie eine Projekt(kosten)kalkulation und ein Projektplan bereitgestellt werden. In der Projektkalkulation wird der Projektumfang und die daraus entstehenden Entwicklungskosten geschätzt. Der Projektplan ist das Resultat sämtlicher Planungsaktivitäten.

Anforderungsanalyse (requirements analysis)

Das Ziel der besteht darin, die Anforderungen des Auftraggebers zu spezifizieren, zu strukturieren und zu prüfen. Schlechte oder nicht vorhandene Anforderungs-Spezifikationen können im Nachhinein einige Probleme und Kosten verursachen, im schlechtesten Fall sogar das Fehlschlagen des gesamten Softwareprojekts. Aus diesem Grund ist die Anforderungsanalyse eine wichtige Voraussetzung für eine erfolgreiche Softwareentwicklung.

Die Ergebnisse der Anforderungsanalyse bzw. Anforderungsspezifikation werden in der Regel in einem Pflichtenheft dokumentiert. Immer häufiger jedoch auch in einem objektorientiertem Analysemodell (OOA-Modell). Außerdem können dem Auftraggeber nach der Analyse und Spezifikation bereits Prototypen der Benutzerschnittstelle bereitgestellt werden um die spezifizierten Anforderungen zu visualisieren. Dadurch können Unklarheiten und Missverständnisse zwischen dem Auftraggeber und Auftragnehmer frühzeitig erkannt und diskutiert werden.

Was ist ein Lastenheft?

Das Lastenheft (auch Anforderungsspezifikation, Anforderungskatalog, Produktskizze, Kundenspezifikation oder Anwenderspezifikation) beschreibt die Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers.

Die Anforderungen sollen dabei quantifizierbar und prüfbar sein. Anforderungen wie: eine moderne oder benutzerfreundliche Oberfläche sind zum Beispiel nicht quantifizierbar und prüfbar. Hier müsste zunächst definiert und diskutiert werden, was eine modern und benutzerfreundliche Oberfläche kennzeichnet.

Zudem sollten alle Anforderungen die im Lastenheft aufgeführt priorisiert werden. Die Priorität spiegelt die Wichtigkeit und somit Reihenfolge der Abarbeitung der Anforderungen wieder. Im Regelfall wird unter high priority, medium priority und low priority unterschieden.

Häufig dient das Lastenheft auch als Ausschreibungs- oder Angebotsgrundlage. Ausgehend von den Anforderungen im Lastenheft, erstellt der Auftragnehmer ein Pflichtenheft und dokumentiert dort wie er die Anforderungen zu lösen gedenkt. Hat der Auftragnehmer noch keinen Projektpartner gefunden, bzw. schreibt er das Projekt öffentlich mit Hilfe eines Lastenheftes aus, kann er anhand des Pflichtenhefts beurteilen wer der geeignetste Auftragnehmer ist.

Das Lastenheft beschreibt die Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers.

Was ist ein Pflichtenheft?

Das Pflichtenheft (requirements specification) beschreibt, wie der Auftragnehmer die zuvor im Lastenheft dokumentierten Anforderungen des Auftraggebers, umzusetzen gedenkt. Die Anforderungsspezifikationen werden um einiges detaillierter beschrieben als die eigentliche Beschreibung der Anforderungen im Lastenheft. Der gesamte Ablauf des Projektes sollte so detailliert wie möglich beschrieben und alle offenen Fragen und Unklarheiten beseitigt werden.

Aufbau, Struktur und Detaillierungsgrad eines Pflichtenheftes variieren stark in der Praxis. Es gibt keinen festgelegten Aufbau, folgende Punkte gehören aber in jedem Fall zur Gliederung eines Pflichtenheftes:

eine Einleitung, welche das Projekt kurz beschreibt,
die Ausgangssituation und Zielbestimmung,
Produkteinsatz und Produktfunktionen,
eine Beschreibung und ein Schema der Produktdaten,
Qualitätsanforderungen,
grundlegende Bestimmung der Benutzeroberfläche,
sonstige nichtfunktionale Anforderungen wie Wartbarkeit, Sicherheit und politische / rechtliche Anforderungen,
ein Glossar, Abkürzungs- und Literaturverzeichnis

Das Pflichtenheft (requirements specification) beschreibt, wie der Auftragnehmer die zuvor im Lastenheft dokumentierten Anforderungen des Auftraggebers, umzusetzen gedenkt.

Die bekanntesten Vertreter bzw. (Vorgehens-)modelle der agilen Softwareentwicklung sind Extreme Programming (XP), Scrum und Kanban.

Objektorientierte Analyse (OOA) und Objektorientiertes Design (OOD)

Viele gängige und moderne Programmiersprachen arbeiten objektorientiert. Häufig wird deshalb neben oder nach der Erstellung des Pflichtenheftes eine Objektorientierte Analyse durchgeführt. Man versucht das Fachkonzept der späteren Anwendung mit objektorientierten Konzepten zu beschreiben. Dazu zählen in erster Linie Klassen, Objekte, Methoden, Vererbung und Attribute - also alle klassischen objektorientierten Grundkonzepte. Hinzu kommen Konzepte zur Objektorientierten Analyse und zum Objektorientierten Design wie Anwendungsfälle, Szenarien und Zustandsautomaten.