Softwareengineering ist nach Balzert (2000) ,,ein Fachgebiet der Informatik, das sich mit der zielorientierten Bereitstellung und systematischen Verwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwareprodukten befaßt``. Hauptziel des Softwareengineering ist eine Steigerung der Produktivität des Softwareentwicklungsprozesses und die Sicherstellung der Qualität der Produkte. Die Faktoren Kosten und Zeit bei der Entwicklung (und Wartung) qualitativ hochwertiger Software sollen minimiert werden.
Ein Vorgehensmodell beschreibt den Lebenszyklus eines Softwareprodukts in Form von Aktivitäten. Durch ein Vorgehensmodell wird festgelegt, in welcher Reihenfolge welche Aktivitäten durchgeführt werden können und welche zeitlichen Überschneidungen zulässig sind. Ein Vorgehensmodell liefert außerdem Informationen über die für eine Aktivität relevanten Objekte und die einzusetzenden Entwicklungsmethoden und -werkzeuge.
Das etablierteste Vorgehensmodell ist das Phasenmodell, wegen seiner sequentiellen Struktur ohne Rücksprünge auch Wasserfallmodell genannt (siehe Abb. 2.1 (a)). Das Phasenmodell besteht aus den vier eigentlichen Entwicklungsphasen Analyse, Entwurf, Implementation und Test sowie der nachgestellten Phase Einsatz und Wartung. Die Phasen sollen dabei sequentiell durchlaufen werden, d.h. eine Phase muß komplett beendet sein, bevor die nächste beginnt.
In der Analysephase wird ermittelt, was das zu erstellende Produkt leisten soll. Die Analyse mündet in die Erstellung des sogenannten Pflichtenheftes, in dem die genauen Anforderungen wie Funktionsumfang, Schnittstellen, Performance (Laufzeit, Speicherbedarf) und Umfang der Dokumentation festgehalten werden und das damit die Vertragsbasis zwischen Auftraggebern und Auftragnehmern bildet. Auf der Grundlage des Pflichtenheftes wird in der Entwurfsphase die Architektur des Softwareproduktes festgelegt. Dazu werden eine schrittweise Zerlegung in einzelne Komponenten durchgeführt sowie die genauen Aufgaben der einzelnen Komponenten und ihre Schnittstellen zueinander definiert. Die programmtechnische Umsetzung der Komponenten in eine konkrete Programmiersprache gemäß der Methoden des Programmierens im Kleinen ist Aufgabe der Implementierungsphase. Die Testphase besteht aus mehreren Teilphasen. Nach dem Einzeltest der Komponenten folgt der Integrationstest, bei dem die Komponenten sukzessive zum kompletten Programm zusammengesetzt werden. Systemtest und Abnahmetest stellen sicher, daß das Produkt die im Pflichtenheft aufgeführten Anforderungen erfüllt. Während der Systemtest durch das Entwicklungsteam vorgenommen wird, erfolgt der Abnahmetest durch die Auftraggeber. Die Einsatz- und Wartungsphase beginnt mit der Installation des Produktes und umfaßt Tätigkeiten wie Fehlerkorrektur, Portierung, Verbesserung und Erweiterung der Software.
Der gravierendste Nachteil, der sich beim praktischen Einsatz des Phasenmodells offenbart hat, ist die sequentielle Abarbeitung der einzelnen Phasen. Insbesondere die in Abschnitt 2.1.3 angesprochenen Anforderungsänderungen während der Entwicklungsphase erfordern eine Aufweichung der strengen Sequentialität. Im iterierten Phasenmodell (siehe Abb. 2.1 (b)) sind daher Rücksprünge in frühere Phasen möglich.
Auftraggeber sind häufig nicht in der Lage, zu Beginn eines Softwareprojektes die gewünschten Anforderungen an das Softwareprodukt präzise bzw. vollständig zu definieren, was aber die Phasenmodelle verlangen. Dieses Problem kann z.B. mit dem Prototypenmodell und mit dem evolutionären Modell gelöst werden. Beim Prototypenmodell wird frühzeitig ein bewußt unvollständiges und vereinfachtes Produkt, ein sogenannter Prototyp, erstellt, mit dem seitens der Auftraggeber experimentiert werden kann, um unklare Anforderungen zu beseitigen (siehe Abb. 2.1 (c)). Beim evolutionären Modell werden zunächst nur die Kernanforderungen an das Produkt realisiert und diese dann iterativ und aufbauend auf den schon realisierten Teilen erweitert. Auftraggeber sammeln jeweils Erfahrungen mit der aktuellen Version des Produktes und definieren zusätzliche Anforderungen (siehe Abb. 2.1 (d)).
Weitere Vorgehensmodelle sind das Modell der transformationellen Softwareentwicklung, das Spiralmodell und das V-Modell. Bei der transformationellen Softwareentwicklung wird in einem iterativen Prozeß aus einer formalen Produktdefinition automatisch ein Programm generiert (siehe Abb. 2.1 (e)). Beim Spiralmodell, dessen Ziel die Risikominimierung ist, handelt es sich um ein sogenanntes Metamodell, das eine Kombination der anderen Modelle erlaubt. Der Entwicklungsprozeß wird in einer Spirale durchlaufen. Jede Windung besteht dabei aus den vier Schritten der Definition der Ziele, Alternativen und Rahmenbedingungen an das in der Windung zu erstellende Teilprodukt, der Evaluierung der Alternativen, der Realisierung und Überprüfung der gewählten Alternative sowie der Bewertung des aktuellen Projektstandes und der Planung der nächsten Spiralwindung (siehe Abb. 2.1 (f)). Beim V-Modell wird nicht nur die Softwareerstellung im engeren Sinne betrachtet, sondern auch die begleitenden Aktivitäten wie Qualitäts-, Konfigurations- und Projektmanagement (siehe auch Abb. 2.2 in Abschnitt 2.2.5).
Eine Softwareentwicklungsmethode enthält Vorschriften zur Durchführung der einzelnen Aktivitäten des Softwareentwicklungsprozesses und Notationen zur Repräsentation entsprechender Ergebnisse.
Die im industriellen Umfeld am weitesten verbreitete Analysemethode ist die Strukturierte Analyse (SA) nach DeMarco. Ziel dieser Methode ist die Ermittlung und Darstellung eines funktions- und datenflußorientierten Modells des Problembereichs. Ausgehend von der Beschreibung der Schnittstellen zur Umwelt werden identifizierte Teilprozesse immer weiter verfeinert. Dabei entsteht eine Hierarchie von Datenflußdiagrammen. Ein Datenflußdiagramm ist dabei eine graphische Notation, mittels der der Weg von Daten zwischen Funktionen zur Transformation von Daten, zum Speichern zur (Zwischen-)Ablage von Daten und Schnittstellen zur Umwelt beschrieben werden kann. Der Zusammenhang zwischen den einzelnen Datenflußdiagrammen der Hierarchie wird mit Regeln einer modifizierten BNF in einem sogenannten Data Dictionary festgehalten. Den Blättern der Hierarchie werden Mini-Spezifikationen zugeordnet. Diese beschreiben die Transformation von Eingabedaten durch das Datenflußdiagramm und werden im allgemeinen in einer Pseudo-Programmiersprache codiert. Für die SA existiert ein Regelwerk, das eine normierte Vorgehensweise bei der Entwicklung der Diagramme vorschlägt.
Eine bekannte Erweiterung der SA ist die Moderne Strukturierte Analyse (MSA) nach Yourdon. Sie ergänzt die Datenflußmodellierung um eine Ereignismodellierung mit Zustandsübergangsdiagrammen (Repräsentation der möglichen Zustände, in die ein Programm gelangen kann, sowie der durch bestimmte Ereignisse implizierten Zustandsänderungen) und eine Datenmodellierung mit Entity-Relationship-Diagrammen.
Eine Methode, die den Entwurf eines Softwaresystems unterstützt, ist die Methode des Strukturierten Entwurfs (Structured Design, SD). Ziel dieser Methode ist die Erstellung einer Softwarearchitektur in Form einer Hierarchie von funktionalen Modulen. Ein funktionales Modul kapselt dabei die Implementierung einer oder mehrerer Funktionen. Nach außen ist lediglich die Schnittstelle sichtbar, die u.a. eine Aufgabenbeschreibung, Ein- und Ausgabe-Parameter sowie Voraussetzungen für den Zugriff beinhaltet. Für die Darstellung der Modulhierarchie werden Strukturdiagramme verwendet, die die Aufrufstruktur und den Datenfluß zwischen den Modulen widerspiegeln.
Neben funktionalen Abstraktionen werden beim Modularen Entwurf/Design (MD) auch Datenabstraktionen betrachtet. Von besonderer Bedeutung ist hierbei der Begriff des Abstrakten Datentyps (ADT). Ein ADT faßt Datenstrukturen und Operationen auf diesen Datenstrukturen zu einer Einheit zusammen. Einfache Beispiele sind Listen und Keller. Das Konzept des ADT erlaubt die Spezifikation der relevanten Eigenschaften von Datenstrukturen, ohne daß Realisierungsaspekte sichtbar werden. Sowohl beim SD als auch beim MD existieren Richtlinien, die dazu dienen, eine qualitativ hochwertige Modularisierung des zu entwickelnden Systems zu finden.
Die Entwurfsphase folgt der Analysephase. Von daher wäre es sinnvoll, in der Entwurfsphase direkt mit den Ergebnissen der Analysephase weiterzuarbeiten. Das ist beim SA und SD bzw. MD jedoch nicht der Fall. Es existieren zwar Ansätze, um SA-Modelle in SD- bzw. MD-Modelle umzusetzen; diese sind aber nur eingeschränkt anwendbar. In Abschnitt 2.3 werden objektorientierte Softwareentwicklungsmethoden vorgestellt, bei denen derartige Strukturbrüche zwischen der Analyse- und Entwurfsphase nicht auftreten.
Aufgaben des Projektmanagements sind die Planung, Organisation, Personalauswahl, Leitung und Kontrolle eines Projektes. Da sich Software bzw. der Entwicklungsprozeß von Software gegenüber anderen Produkten unterscheidet (siehe Abschnitt 2.1), ist das Ziel dieses Teilbereichs des Softwareengineering die Entwicklung und Bereitstellung geeigneter Methoden und Werkzeuge für die Verwaltung und Durchführung von Softwareprojekten.
Gegenstand der Projektplanung ist die Erstellung eines Projektplans, aus dem hervorgeht, welche (Teil-)Aufgaben wie, durch wen und bis wann zu erledigen sind. Dabei müssen vor allem kalkulierte Kosten und Termine (Meilensteine) berücksichtigt werden. Aufgrund der nur schwer meßbaren Qualität von Software ist die Projektplanung ein ausgesprochen schwieriger Prozeß, der viel Erfahrung verlangt.
Bei der Projektorganisation werden zwei Teilaufgaben unterschieden: die Ablauforganisation und die Aufbauorganisation. Die Ablauforganisation bestimmt den genauen Arbeitsablauf gemäß des gewählten Vorgehensmodells. Die Aufbauorganisation dient der Koordinierung des Entwicklungsteams, indem sie z.B. Gruppenstruktur, Zuständigkeiten und Verantwortlichkeiten festlegt.
Die Heterogenität eines Softwareentwicklungsteams und die hohe Fluktuation der Fachkräfte implizieren besondere Anforderungen an die Personalauswahl. Die Personen müssen neben speziellen inhaltlichen Qualifikationen insbesondere die Fähigkeit zur Teamarbeit besitzen. Sie müssen weiterhin durch geeignete Maßnahmen wie angemessenes Gehalt, gute Zukunftsperspektiven und ein attraktives Arbeitsumfeld motiviert werden.
An die Leitung eines Softwareentwicklungsteams werden wegen der Heterogenität des Teams hohe Anforderungen gestellt. Neben der Personalführung und dem Delegieren von Aufgaben gehören die Fähigkeiten zur Unterstützung der Kommunikation und zur Vermeidung bzw. Behebung von Konflikten zu den erforderlichen Qualifikationen. Die rasante Weiterentwicklung der Informationstechnologien verlangt darüber hinaus ein innovationsfreudiges und dennoch risikobewußtes Projektmanagement.
Aufgabe der Kontrolle eines Softwareentwicklungsprojektes ist die ständige Überprüfung der Übereinstimmung des aktuellen Projektstatus mit dem Projektplan. Treten wesentliche Abweichungen vor allem bezüglich der veranschlagten Kosten oder Meilensteine auf, müssen geeignete Maßnahmen ergriffen werden.
Professionelle Softwareentwicklung ist heutzutage ohne den Einsatz unterstützender Softwarewerkzeuge nicht mehr denkbar. Sogenannte Softwareenwicklungsumgebungen oder CASE-Umgebungen (Computer Aided Software Engineering) zielen auf die Steigerung der Produktivität und die Erleichterung des Managements während des Entwicklungsprozesses sowie die Verbesserung der Qualität des entstehenden Softwareproduktes. CASE-Umgebungen bestehen aus einem Rahmensystem (Framework), das allgemeine Dienstleistungen wie eine konsistente Datenverwaltung, eine einheitliche, intuitive Bedienoberfläche und Funktionen zur Kooperation der Projektmitglieder bietet, sowie einer Reihe ergänzender Werkzeuge, die in das Rahmensystem integriert sind.
CASE-Umgebungen unterstützen im allgemeinen ein oder auch mehrere Vorgehensmodelle und Entwicklungsmethoden. Die eingesetzten Werkzeuge helfen dabei dem Entwicklungsteam sowohl bei der Bearbeitung phasenspezifischer als auch phasenübergreifender Aktivitäten. Sie übernehmen z.B. Routinearbeiten und überwachen die Konsistenz, Redundanzfreiheit und Vollständigkeit der erstellten (Teil-)Produkte. Typische Beispiele für CASE-Werkzeuge sind Graphikeditoren zur effizienten Erstellung bzw. Manipulation konkreter Diagramme eines bestimmten Diagrammtyps.
Ziel des Softwarequalitätsmanagements ist die jederzeitige Gewährleistung festgelegter Qualitätsanforderungen sowohl an das zu entwickelnde Softwareprodukt als auch an den Softwareentwicklungsprozeß selbst. Um dieses Ziel zu erreichen, werden Qualitätssicherungsmaßnahmen entwicklungsbegleitend eingesetzt (siehe Abb. 2.2). Es werden dabei konstruktive und analytische Maßnahmen unterschieden. Konstruktive Qualitätssicherungsmaßnahmen streben durch den Einsatz qualitätssichernder Methoden, Richtlinien und Werkzeuge an, daß das Produkt per se die Qualitätsanforderungen erfüllt. Durch analytische Maßnahmen wird hingegen die Qualität von fertiggestellten (Teil-)Produkten im nachhinein gemessen, was gegebenenfalls Korrekturmaßnahmen erforderlich macht.
Beim Qualitätsmanagement werden drei Aktivitäten unterschieden: Ziel der Qualitätsplanung ist eine überprüfbare Festlegung der Qualitätsanforderungen in einem Qualitätssicherungsplan. Die Qualitätslenkung und -sicherung steuert und überwacht die korrekte Umsetzung des Plans. Die Qualitätsüberprüfung erfaßt Ist-Werte und überprüft diese mit den im Plan spezifizierten Soll-Werten.
Das Qualitätsmanagement basiert dabei insbesondere auf folgenden Prinzipien:
Die Erfahrung hat gezeigt, daß die Qualität eines Produktes wesentlich durch die Qualität des Entwicklungsprozesses beeinflußt wird. Um die Prozeßqualität zu verbessern, wird daher z.B. im ISO 9000-Standard der Softwareentwicklungsprozeß durch Modelle, Methoden und Richtlinien normiert. Insbesondere werden allgemeingültige Anforderungen an die Aufbau- und Ablauforganisation eines Entwicklungsunternehmens gestellt. Die Erfüllung der ISO 9000-Anforderungen kann sich ein Unternehmen durch ein sogenanntes ISO 9000-Zertifikat bescheinigen lassen.
Im Laufe des Softwareentwicklungsprozesses entstehen eine Menge von Softwareelementen (Teilprodukte und Dokumente) wie Programmcode, Pflichtenheft, Entwurfsdokumentation, Benutzungshandbuch und Testszenarien. Diese Softwareelemente unterliegen dabei stetigen Änderungen. Um unterschiedliche Versionen eines Softwareelementes zu verschiedenen Zeitpunkten unterscheiden zu können, werden die Elemente mit Versionsnummern gekennzeichnet. Zwischen den Elementen bzw. einzelnen Versionen von verschiedenen Elementen existieren diverse Beziehungen. Eine Menge solcher miteinander verflochtener Elemente in einer speziellen, insgesamt aufeinander abgestimmten Version bildet eine sogenannte Softwarekonfiguration.
Ziel des Softwarekonfigurationsmanagements ist eine effiziente Verwaltung von Softwarekonfigurationen durch geeignete Methoden und Werkzeuge. Der gesamte Entwicklungsprozeß muß aufgezeichnet werden, um auch später noch Änderungen nachvollziehen, überprüfen und evtl. rückgängig machen zu können, ohne in einen inkonsistenten Zustand zu geraten.
Eine zentrale Aufgabe des Softwarekonfigurationsmanagements ist die Versionsverwaltung, die durch spezielle Versionsmanagementsysteme unterstützt wird. Diese verwenden im allgemeinen das sogenannte Checkin/Checkout-Modell. Bei diesem Modell werden die verschiedenen Versionen der Softwareelemente in einem Archiv gesammelt. Durch eine Checkout-Operation kann jemand eine Kopie eines Elementes aus dem Archiv holen, Änderungen hieran vornehmen und das geänderte Element wieder in das Archiv zurückspielen. Dabei werden automatisch weitere Informationen wie Verursacher oder Zeitpunkt der Änderung vermerkt. Zur Vermeidung von Änderungskonflikten ist bei vielen Systemen ein ausgechecktes Element bis zur Checkin-Operation exklusiv für eine Person reserviert. Moderne Systeme erlauben mehrfache Checkouts desselben Elementes und stellen geeignete Mechanismen für eine eventuell erforderliche spätere Konfliktbehebung bereit.
