Was ist der Softwareentwicklungszyklus?

Der Softwareentwicklungszyklus (SDLC) ist ein Prozess, den Entwicklungsteams verwenden, um qualitativ hochwertige Software effizient und kostengünstig zu erstellen. Er umfasst mehrere Schritte, denen Teams folgen können, um Software auf vorhersehbare und geordnete Weise zu entwickeln.

Wie funktioniert der SDLC?

Der SDLC ist in verschiedene Phasen unterteilt, die es den Teams ermöglichen, Software auf konsistente und qualitativ hochwertige Weise zu entwickeln. Man kann ihn als virtuelle Produktionslinie für Softwareprodukte betrachten. Obwohl jede Organisation einen einzigartigen Ansatz für die Softwareentwicklung hat, betrachten viele den SDLC in den folgenden Phasen:

Planung

In dieser Phase legen die Teams die Softwareanforderungen gründlich fest. Sie nutzen Ressourcen wie Kundenfeedback, Marktforschung, interne Fachexperten und externe Stakeholder, um einen konkreten Plan zu erstellen. Während dieser Phase zielt das Entwicklungsteam darauf ab, die folgenden Details festzulegen:

  • Ressourcenzuweisung
  • Kostenanalyse
  • Projektzeitplan
  • Spezifische Ziele
  • Softwareanforderungsspezifikationen (SRS)

Anschließend müssen die obigen Anforderungen den zuständigen Stakeholdern zur Genehmigung vorgelegt werden.

Design

Als Nächstes nehmen die Entwickler die in der ersten Phase festgelegten Anforderungen und entwerfen die Architektur zur Erstellung des Produkts. In dieser Phase erstellen sie eine Design-Dokumentationsspezifikation (DDS), die die Werkzeuge festlegt, die sie verwenden werden, und wie diese Technologien in bestehende Technologiestacks integriert werden.

Implementierung

Die Entwickler gehen dann in die Implementierungsphase über, in der sie den Code schreiben, der schließlich das Endprodukt wird. Sie unterteilen die Gesamtanforderungen in kleinere Einheiten, die zu ihren täglichen Aufgaben werden, bis das gesamte Projekt abgeschlossen ist.

Mehrere Programmierwerkzeuge, wie Compiler, Interpreter und Debugger, ermöglichen es den Entwicklern, Code-Schnipsel auf einzelnen Maschinen zu erstellen. Die Entwickler integrieren dann diese einzelnen Teile in ein zentrales Repository, wo sie zusammengefügt werden, um das vollständige Produkt zu erstellen.

Testen

Als Nächstes testet das Entwicklungsteam die Qualität ihres Produkts mithilfe einer Mischung aus automatisierten und manuellen Tests. Sie testen die Qualität und Funktionalität und stellen sicher, dass das Produkt den in den vorherigen Phasen festgelegten Standards und Anforderungen entspricht. Teams erstellen in dieser Phase häufig Softwaredokumentationen, um sicherzustellen, dass zukünftige Teams schnell in die Wartung der Software einsteigen können.

Bereitstellung

Nach den Tests ist die Software bereit für die Bereitstellung. Organisationen stellen Software oft in Phasen bereit und veröffentlichen sie zunächst für spezifische Kunden oder Stakeholder für Beta-Tests, bevor sie sie der breiten Öffentlichkeit zugänglich machen. Diese „Testphase“ der neuen Software stellt sicher, dass das neue Produkt in einer realen Umgebung funktioniert.

Wartung

Zuletzt pflegt das Team die Software und überwacht die Systemleistung, Sicherheit und Benutzererfahrung. Dann verwenden sie diese Beobachtungen oder Benutzerberichte, um Korrekturen zu veröffentlichen.

Teams pflegen oft separate Build- und Produktionsumgebungen, damit sie die Software iterativ verbessern können, ohne die Live-Version zu beeinflussen. Sie halten eine Kopie der Software in der Produktionsumgebung live, während eine andere funktionsfähige Kopie in einer Build-Umgebung bleibt. Updates werden in der Build-Umgebung vorgenommen und veröffentlicht, sobald eine ausgereifte Version bereit ist. Auf diese Weise bleibt die Software den Kunden weiterhin zugänglich, während das Team im Hintergrund daran arbeitet, sie zu verbessern und zu warten.

Was sind SDLC-Modelle?

Teams neigen dazu, einige gängige SDLC-Modelle zu verwenden, die auf ihrer IT-Struktur, den Teamprozessen und den allgemeinen Zielen der Organisation basieren. Hier sind einige Beispiele für häufig verwendete Modelle:

Wasserfall

Wie der Name schon sagt, ähnelt dieses Modell konzeptionell einem Wasserfall. Das Team bearbeitet eine Phase, und sobald diese abgeschlossen ist, „fließt“ sie sequentiell in die nächste Phase über. Während dieses Modell es den Teams ermöglicht, nach jeder Phase vollständige Ergebnisse zu sehen und sich an einen stark strukturierten Zeitplan zu halten, erschwert es Änderungen, sobald jede Phase abgeschlossen ist. Wenn also später im Projekt ein Problem auftritt, dauert es länger und ist kostspieliger, es zu beheben.

Iterativ

In diesem Prozess verbringt das Team weniger Zeit in den Planungs- und Designphasen und geht stattdessen mit einem kleinen Teil der Anforderungen in die Implementierungsphase. Anschließend veröffentlichen sie im Laufe der Zeit verschiedene Versionen, bis die Software bereit zur Bereitstellung ist. Obwohl dieser Ansatz es den Teams ermöglicht, sich an neue Probleme anzupassen, ist es auch schwieriger, die Zeit und Kosten für das gesamte Projekt genau zu schätzen.

Spiralmodell

Das Spiralmodell ist eine Kombination aus den Modellen Iterativ und Wasserfall. In diesem Modell durchläuft die Entwicklung Release-Zyklen in der Reihenfolge eines Wasserfallprozesses, verwendet jedoch ein kleines Teilset an Anforderungen. Dieses Verfahren funktioniert am besten für große und komplexe Projekte, da es bei kleineren Projekten kostspielig werden kann.

Agiles Modell

Die agile Methodik verfolgt einen inkrementellen Ansatz zur Softwareentwicklung. Teams veröffentlichen kleinere Einheiten in Sprints, anstatt wie beim Wasserfallmodell zu warten, bis eine gesamte SDLC-Phase abgeschlossen ist, bevor sie zur nächsten übergehen. Viele moderne Teams verwenden einen agilen Ansatz, und Aras-Lösungen unterstützen diesen Ansatz.

Durch die Nutzung des agilen Modells können Teams Probleme frühzeitig besser identifizieren und angehen, sodass Korrekturen vorgenommen werden können, ohne andere Projektbereiche zu beeinträchtigen. Viele agile Teams sammeln auch früher im Lebenszyklus Feedback, das sie leichter integrieren können, ohne die Kosten oder Ressourcen dramatisch zu beeinflussen. Diese Methode ist jedoch anfälliger für unerwartete Umfangsänderungen, da sie zu Beginn des Prozesses mehr Variablen einführt.

V-förmiges (auch „Verifikations-“ oder „Validierungsmodell“) Modell

Dieses Modell konzentriert sich darauf, kleinere Tests wie Unit- und Integrationstests während der Implementierungsphase durchzuführen. Diese Mentalität des „frühen und häufigen“ Testens ermöglicht es den Teams, Fehler und Qualitätsprobleme frühzeitig im Zyklus zu erkennen. Es reduziert die Anzahl der Korrekturen, die die Entwickler später im Lebenszyklus vornehmen müssen. Da es Tests mit jeder Phase der Entwicklung kombiniert, ist das V-förmige Modell ressourcen- und zeitintensiver als andere Methoden.

Big-Bang-Modell

Dieses Modell konzentriert sich einfach darauf, Software ohne festgelegte Anforderungen oder Planung zu veröffentlichen. Die Projektziele sind gut genug verstanden, ohne dass ein schriftlicher Plan vorliegt, und der Code wird ad hoc erstellt, um das Endprodukt zu generieren. Dieses informelle Entwicklungsmodell kann nur für kleine Teams mit vagen Zielen und Fristen funktionieren. Es wird hauptsächlich in akademischen Umgebungen verwendet.

Wie berücksichtigt der SDLC die Sicherheit?

Während Teams einen Softwareentwicklungszyklus aufbauen, müssen sie auch die Cybersicherheit berücksichtigen. Viele Teams entscheiden sich für einen DevSecOps-Ansatz, der die Sicherheit in jede Phase des SDLC integriert. Im Rahmen der DevSecOps-Methodik führen Teams Sicherheitsaktivitäten wie Code-Überprüfungen in jeder Phase der Entwicklung durch. Beispielsweise könnte ein Entwickler einen statischen Anwendungssicherheitstest (SAST) auf eine Code-Einheit ausführen, bevor er diese in das zentrale Repository überträgt. Durch die frühzeitige Behebung von Sicherheitsproblemen im SDLC können Teams Code-Schwachstellen und andere Sicherheitsmängel beheben, bevor das Problem später in der Pipeline weiter ausgebaut wird.

Vorteile des SDLC

Wenn Teams den SDLC zur Veröffentlichung von Software verwenden, profitieren sie von mehreren Vorteilen, darunter:

  • End-to-End-Transparenz des gesamten Prozesses, dokumentiert für alle Stakeholder
  • Genauere Schätzungen der erforderlichen Kosten, Zeit und Ressourcen
  • Insgesamt bessere Produkte, da dieser Prozess Kundenfeedback, interne Expertise sowie eingehende funktionale und Qualitätskontrollen berücksichtigt

Teams, die benutzerdefinierte Softwareinstanzen veröffentlichen müssen, wie z. B. angepasste Produktlebenszyklus-Management (PLM)-Technologie, profitieren von diesen Vorteilen, wenn sie den SDLC zur Veröffentlichung von Funktionen nutzen. Diese bewährte Struktur zur Veröffentlichung von Software ermöglicht es ihnen, eine benutzerdefinierte Instanz zu erstellen, die auf ihre Benutzer und spezifischen Anforderungen zugeschnitten ist. Anders als Software, die als Produkt an Unternehmen oder Kunden verkauft wird, wird die benutzerdefinierte PLM-Lösung von internen Benutzern in einer Organisation, wie z. B. Ingenieuren, verwendet. In diesem Fall müssen Teams die technologischen Funktionen berücksichtigen, die diese „internen Kunden“ benötigen, um hochwertige physische Produkte zu bauen. Ihre Anforderungen und praktischen Anwendungsfälle werden Teil der Planungs- und Entwurfsphasen des Softwareentwicklungszyklus der PLM-Plattform.