Was ist der Software Development Cycle / Software-Lebenszyklus?
Der Software Development Cycle (SDLC), oder auf Deutsch Softwareentwicklungszyklus, ist ein strukturierter Prozess, dem Softwareentwicklungsteams folgen, um hochwertige Software zu entwerfen, zu entwickeln, zu testen und bereitzustellen. Er unterteilt die komplexe Aufgabe der Softwareerstellung in kleinere, überschaubare und aufeinanderfolgende Phasen. Das Hauptziel des SDLC ist es, den Entwicklungsprozess zu standardisieren, die Effizienz zu steigern und sicherzustellen, dass das Endprodukt die Anforderungen des Kunden erfüllt.
Die Kernphasen des Softwareentwicklungszyklus sind in der Regel die folgenden:
Planung und Anforderungsanalyse: Dies ist die grundlegende Phase. Hier werden die Anforderungen des Kunden gesammelt, analysiert und dokumentiert. Es wird festgelegt, was die Software tun soll, welche Ressourcen benötigt werden und ein Projektplan erstellt.
Design: In dieser Phase entwerfen die Architekten und Entwickler die technische Architektur der Software. Sie legen die Systemarchitektur, die Datenbankstruktur, die Benutzeroberfläche (UI/UX) und die einzelnen Module fest. Das Ergebnis ist ein detaillierter Entwurfsplan.
Implementierung (Codierung): Hier schreiben die Entwickler den eigentlichen Code in einer ausgewählten Programmiersprache. Sie setzen die im Designdokument festgelegten Spezifikationen in funktionierende Software um. Dies ist oft die längste Phase des Zyklus.
Testen: Sobald der Code geschrieben ist, wird die Software rigoros getestet, um Fehler (Bugs) zu finden und zu beheben. Tester überprüfen, ob die Software alle Anforderungen erfüllt, stabil läuft und benutzerfreundlich ist. Verschiedene Testarten wie Unit-Tests, Integrationstests und Systemtests kommen hier zum Einsatz.
Bereitstellung (Deployment): Nach erfolgreichem Test wird die Software für die Endbenutzer freigegeben und in einer Produktionsumgebung installiert. Dies kann ein schrittweiser Rollout oder eine vollständige Veröffentlichung sein.
Wartung und Betrieb: Nach der Bereitstellung beginnt die Phase der Wartung. Das Entwicklungsteam behebt auftretende Fehler, nimmt Aktualisierungen vor und fügt im Laufe der Zeit neue Funktionen hinzu, um die Software aktuell und funktionsfähig zu halten.
Es gibt verschiedene Modelle zur Umsetzung des SDLC, wie das Wasserfallmodell (ein linearer, sequenzieller Ansatz) und agilere Methoden wie Scrum oder Kanban, die auf iterative Entwicklung in kurzen Zyklen setzen. Die Wahl des Modells hängt von den Projektanforderungen, der Teamgröße und der Unternehmenskultur ab.
Was ist der Softwareentwicklungszyklus (Software Development Life Cycle - SDLC) und was beschreibt er im Kern?
Der SDLC ist ein Konzept, das den gesamten Lebenszyklus einer Software beschreibt und erklärt, worauf man in einem Softwareprojekt achten muss.
Er ist selbst kein spezifisches Prozessmodell (wie Scrum oder Wasserfall), sondern ein übergeordneter Rahmen, der Folgendes umfasst:
Eine Reihe von Aufgaben und Phasen (z.B. Planung, Entwicklung, Testen). Wichtige Managementaspekte des gesamten Prozesses.
Sind die Aspekte im Software-Lebenszyklus (z.B. Wartung, Requirements Engineering) streng sequenzielle Phasen?
Nein, der Begriff ‘Phase’ ist irreführend. Die Aspekte können sich wiederholen, überlappen und müssen nicht in einer festen Reihenfolge ablaufen.
Was ist ein Softwareprozessmodell?
Ein Softwareprozessmodell (oft auch Vorgehensmodell genannt) ist ein strukturierter Plan, der den Ablauf eines Softwareprojekts in überschaubare Phasen unterteilt. Es legt fest, welche Schritte in welcher Reihenfolge ausgeführt werden, um die Software erfolgreich zu entwickeln.
Bekannte Beispiele sind das Wasserfallmodell und agile Modelle wie Scrum.
Was ist ein Softwareprozessmodell und wie unterscheidet es sich vom Softwareentwicklungszyklus (SDLC)?
Ein Softwareprozessmodell ist eine konkrete Lösungsstrategie, um Software zu managen und zu entwickeln.
Im Gegensatz zum SDLC (der nur beschreibt, welche Phasen es gibt), gibt ein Prozessmodell vor, wie diese Phasen durchlaufen werden. Es kann Unterstützung für den gesamten Lebenszyklus oder nur für Teile davon bieten.
Beispiele: Wasserfallmodell, Scrum, V-Modell.
Wie lassen sich Softwareprozessmodelle unterteilen und was kennzeichnet die beiden Haupttypen?
Softwareprozessmodelle lassen sich in phasenbasierte und iterative Modelle unterteilen.
Phasenbasierte Modelle:
Jede Phase beinhaltet unterschiedliche Arten von Aufgaben (z.B. erst nur Analyse, dann nur Design).
Die Phasen folgen einer strengen, sequenziellen Reihenfolge. Ein klassisches Beispiel ist das Wasserfallmodell.
Iterative Modelle:
Dieselbe Art von Aufgaben (Analyse, Design, Implementierung) wird in Wiederholungen (Iterationen) durchgeführt.
In jeder Iteration werden neue Artefakte erstellt oder bestehende erweitert. Dies ermöglicht ein schrittweises Wachstum der Software.
Neben “phasenbasiert” und “iterativ”, welche weitere Unterteilung von Softwareprozessmodellen gibt es und worauf legen diese Ansätze ihren Fokus?
Artefaktzentrierte Modelle
Der Fokus liegt auf dem zu erstellenden Produkt (Artefakt) und dessen Qualität.
Es geht primär um das Ergebnis (Was wird erstellt?).
Prozesszentrierte Modelle:
Der Fokus liegt auf der Beschreibung der Aufgaben und der Interaktion der verschiedenen Rollen im Team.
Es geht primär um den Ablauf (Wie wird es erstellt?).
Was unterscheidet “light-weight” von “heavy-weight” Softwareprozessmodellen?
Der Hauptunterschied liegt in der Freiheit, die Entwickler in ihrem Vorgehen haben.
Light-weight Modelle (leichtgewichtig)
Heavy-weight Modelle (schwergewichtig)
Was ist das Wasserfallmodell und was ist sein zentrales Merkmal?
Es ist ein Softwareprozessmodell, das die Aspekte des Lebenszyklus als strikt sequenzielle, aufeinanderfolgende Phasen anordnet.
Das Wasserfallmodell ist ein klassisches, lineares Vorgehensmodell für die Softwareentwicklung.
Zentrales Merkmal: Das Projekt wird in streng aufeinanderfolgende Phasen unterteilt, die nacheinander “wie ein Wasserfall” durchlaufen werden. Eine neue Phase beginnt erst, wenn die vorherige vollständig abgeschlossen ist. Rücksprünge sind nicht vorgesehen.
Typische Phasen:
Ideal für: Projekte mit klaren, stabilen und von Anfang an bekannten Anforderungen.
Nachteil: Sehr unflexibel bei späteren Änderungswünschen.
Was ist das V-Modell und was ist sein zentrales Merkmal im Vergleich zum Wasserfallmodell?
Das V-Modell ist eine Erweiterung des Wasserfallmodells. Sein zentrales Merkmal ist die enge Verknüpfung von Entwicklung und Qualitätssicherung.
In der V-Form wird jeder Phase der Spezifikation und des Entwurfs (linker Ast, abwärts) eine entsprechende Testphase (rechter Ast, aufwärts) direkt gegenübergestellt.
Leitgedanke:
Links (Entwurf): Was soll gebaut werden?
(Anforderungen -> Systemdesign -> Komponentendesign)
Rechts (Test): Wurde es richtig gebaut?
(Komponententest -> Integrationstest -> Systemtest -> Abnahmetest)
Hauptvorteil: Der Fokus liegt auf einer frühen Qualitätssicherung, da Tests von Anfang an mitgeplant werden. Fehler werden dadurch früher im Prozess entdeckt.
Welche Rolle spielen Requirements im V-Modell?
Sie sind fundamental. Sie werden ganz am Anfang definiert und bilden die Basis für alle nachfolgenden Entwicklungs- und Testschritte. Fehler hier führen zwangsläufig zum falschen Produkt.
Wie werden Requirements im Verlauf des V-Modells weiterverwendet?
Sie werden schrittweise verfeinert und transformiert – von den System-Requirements zum Systemdesign, Feindesign und schließlich zu den Spezifikationen für die Implementierung.
Was ist Scrum?
Scrum ist ein agiles Framework für das Projektmanagement, insbesondere in der Softwareentwicklung. Es ist kein starrer Prozess, sondern ein flexibler Rahmen, um komplexe Produkte zu entwickeln.
Kernidee: Das Projekt wird in kurze, feste Zeitabschnitte unterteilt, die Sprints (meist 2-4 Wochen) genannt werden. Am Ende jedes Sprints wird ein fertiges, potenziell auslieferbares Produkt-Inkrement (Teilstück) geliefert.
Die 3 Säulen von Scrum:
Transparenz: Alle wichtigen Aspekte des Prozesses sind für alle sichtbar.
Überprüfung: Regelmäßige Kontrolle des Fortschritts.
Anpassung: Schnelle Reaktion auf Änderungen.
Wichtige Rollen:
Product Owner: Definiert die Anforderungen und priorisiert sie (das “Was”).
Scrum Master: Sorgt dafür, dass das Team die Scrum-Regeln einhält und Hindernisse beseitigt (der “Prozess”).
Entwicklungsteam: Setzt die Anforderungen um (das “Wie”).
Warum wurde Scrum entwickelt?
Als Reaktion auf die Probleme starrer Modelle wie dem V-Modell, insbesondere um besser auf sich ändernde Anforderungen reagieren zu können und weil Anforderungen am Anfang oft unklar sind.
Was ist das Agile Manifesto?
Es ist ein Aufruf von Softwareentwicklern, der den Fokus auf Individuen und Interaktionen, funktionierende Software, Zusammenarbeit mit dem Kunden und das Reagieren auf Veränderung legt, anstatt auf starre Prozesse und umfassende Dokumentation.
Wie behandelt Scrum Anforderungen im Vergleich zum V-Modell?
Statt formaler Requirements werden User Stories im Product Backlog verwendet, die den Kontext (wer, was, warum) beibehalten und implizit viele Anforderungen abdecken, die im V-Modell explizit sein müssten.
Was versteht man unter der ‘frühen Phase’ im Software Engineering?
Es ist die oft chaotische, nicht formalisierte Anfangsphase eines Projekts, in der Domänenverständnis, Anforderungserhebung, erste Design-Entscheidungen, Kostenschätzung und Projektplanung parallel und iterativ stattfinden.
Warum wird der Begriff ‘frühe Phase’ verwendet?
Weil die Aktivitäten (Domäne, Requirements, Design) stark miteinander verknüpft sind, sich gegenseitig beeinflussen und nicht sauber getrennt werden können, wie es klassische Prozessmodelle vorsehen.
Was sind die Herausforderungen der frühen Phase?
Die Informationen sind oft unpräzise, informal und inkonsistent. Der Prozess ist nicht formalisiert, chaotisch und stark von der Expertise und Kommunikation der beteiligten Personen abhängig.
Was bedeutet “Tailoring” im Kontext von Softwareprozessmodellen?
Tailoring (dt. Maßschneidern) bedeutet, dass Softwareprozessmodelle nicht starr sind, sondern an die konkreten Bedürfnisse eines bestimmten Projekts angepasst werden.
Anstatt einem Modell stur zu folgen, werden dessen Prozesse, Artefakte und Regeln so modifiziert, dass sie optimal zum Projekt, zum Team und zum Unternehmen passen. Moderne Ansätze gehen sogar so weit, einzelne starre Strategien komplett zu überwinden und flexibel zu kombinieren.
“Das Anpassen eines Standard-Prozessmodells (wie Scrum oder V-Modell) an die spezifischen Gegebenheiten und Bedürfnisse eines Unternehmens oder Projekts”
Was ist das Ziel einer Retrospektive in Scrum?
Das Team lernt aus dem vergangenen Sprint, indem es reflektiert, was gut und was schlecht lief. Ziel ist die kontinuierliche Verbesserung des eigenen Arbeitsprozesses.
Was ist der Unterschied zwischen Product Backlog und Sprint Backlog?
Das Product Backlog enthält alle Anforderungen für das gesamte Produkt (User Stories). Das Sprint Backlog enthält nur die Aufgaben, die das Team sich für den aktuellen, zeitlich begrenzten Sprint vorgenommen hat.
Was ist die ‘Definition of Done’ (DoD)?
Eine vom Team gemeinsam erstellte Checkliste, die Kriterien festlegt, wann ein Backlog-Item (z.B. eine User Story) als vollständig fertiggestellt gilt (z.B. Code geschrieben, getestet, dokumentiert)
Warum sind User Stories in Scrum keine klassischen Requirements?
Weil sie den Kontext (Akteur, Ziel) beibehalten und viele nicht-funktionale Anforderungen (z.B. Antwortzeiten) implizit durch diesen Kontext definieren, anstatt sie explizit aufzulisten.