Referenz: Sommerville, Software Engineering, 10. Aufl., Kapitel 2

Ein Softwareprozess ist ein strukturierter Satz von Aktivitäten, die zur Entwicklung eines Softwaresystems erforderlich sind. Beachten Sie, dass wir von einem „Softwareprozess“ sprechen – nicht von einem „Softwareentwicklungsprozess“.“

Es gibt viele verschiedene Arten von Software-Prozessen, aber jeder von ihnen beinhaltet diese vier Arten von grundlegenden Aktivitäten:

• Softwarespezifikation – Definieren, was das System tun soll;
• Software-Design und -Implementierung – Definieren der Organisation des Systems und Implementieren des Systems;
• Software-Validierung – Überprüfen, ob es das tut, was der Kunde will;
• Software-Evolution – Ändern des Systems als Reaktion auf sich ändernde Kundenanforderungen.

Ein Software-Prozessmodell ist eine abstrakte Darstellung eines Prozesses. Es stellt eine Beschreibung eines Prozesses aus einer bestimmten Perspektive dar. Wenn wir Softwareprozesse beschreiben und diskutieren, sprechen wir in der Regel über die Aktivitäten in diesen Prozessen, wie z. B. die Spezifikation eines Datenmodells, den Entwurf einer Benutzeroberfläche usw. und die Reihenfolge dieser Aktivitäten.Prozessbeschreibungen können auch enthalten:

• Produkte, die das Ergebnis einer Prozessaktivität sind;
• Rollen, die die Verantwortlichkeiten der am Prozess beteiligten Personen widerspiegeln;
• Vor- und Nachbedingungen, die Aussagen sind, die wahr sind, bevor und nachdem eine Prozessaktivität ausgeführt oder ein Produkt produziert wurde.

Plangesteuerte Prozesse sind Prozesse, bei denen alle Prozessaktivitäten im Voraus geplant werden und der Fortschritt an diesem Plan gemessen wird. In agilen Prozessen erfolgt die Planung inkrementell, und es ist einfacher, den Prozess zu ändern, um veränderte Kundenanforderungen zu berücksichtigen. In der Praxis enthalten die meisten praktischen Prozesse Elemente sowohl von planorientierten als auch von agilen Ansätzen.

Das Wasserfallmodell Plangesteuertes Modell. Getrennte und unterschiedliche Phasen der Spezifikation, des Softwaredesigns, der Implementierung, des Testens und der Wartung. Inkrementelle Entwicklung Spezifikation, Entwicklung und Validierung sind ineinander verschachtelt. Das System wird in einer Reihe von Versionen (Inkrementen) entwickelt, wobei jede Version die Funktionalität der vorherigen Version erweitert. Kann planvoll oder agil sein. Integration und Konfiguration Basiert auf dem Vorhandensein einer beträchtlichen Anzahl von wiederverwendbaren Komponenten/Systemen. Der Systementwicklungsprozess konzentriert sich darauf, diese Komponenten in ein System zu integrieren, anstatt sie von Grund auf neu zu entwickeln. Kann planorientiert oder agil sein.

In der Praxis werden die meisten großen Systeme mit Hilfe eines Prozesses entwickelt, der Elemente aus allen diesen Modellen enthält.

Im Wasserfallmodell gibt es verschiedene identifizierte Phasen:

Anforderungsanalyse und -definition Die Dienste, Einschränkungen und Ziele des Systems werden in Absprache mit den Systembenutzern festgelegt. Sie werden dann im Detail definiert und dienen als Systemspezifikation. System- und Softwareentwurf Der Systementwurfsprozess ordnet die Anforderungen entweder Hardware- oder Softwaresystemen zu, indem eine Gesamtsystemarchitektur festgelegt wird. Der Softwareentwurf umfasst die Identifizierung und Beschreibung der grundlegenden Abstraktionen des Softwaresystems und ihrer Beziehungen. Implementierung und Unit-Tests In dieser Phase wird der Softwareentwurf als eine Reihe von Programmen oder Programmeinheiten realisiert. Bei den Unit-Tests wird überprüft, ob jede Einheit ihrer Spezifikation entspricht. Integration und Systemtest Die einzelnen Programmeinheiten oder Programme werden integriert und als Gesamtsystem getestet, um sicherzustellen, dass die Softwareanforderungen erfüllt werden. Nach dem Test wird das Softwaresystem an den Kunden ausgeliefert. Betrieb und Wartung Normalerweise (aber nicht unbedingt) ist dies die längste Phase des Lebenszyklus. Das System wird installiert und in Betrieb genommen. Die Wartung umfasst die Korrektur von Fehlern, die in früheren Phasen des Lebenszyklus nicht entdeckt wurden, die Verbesserung der Implementierung von Systemeinheiten und die Erweiterung der Dienste des Systems, wenn neue Anforderungen entdeckt werden.

Der größte Nachteil des Wasserfallmodells ist die Schwierigkeit, Änderungen zu berücksichtigen, nachdem der Prozess bereits angelaufen ist. Im Prinzip muss eine Phase abgeschlossen sein, bevor man zur nächsten Phase übergeht. Zu den Problemen des Wasserfallmodells gehören:

Schwierige Berücksichtigung von Änderungen Die unflexible Aufteilung des Projekts in verschiedene Phasen erschwert es, auf sich ändernde Kundenanforderungen zu reagieren, weshalb dieses Modell nur dann geeignet ist, wenn die Anforderungen gut bekannt sind und während des Entwurfsprozesses nur wenige Änderungen vorgenommen werden. Nur wenige Geschäftssysteme haben stabile Anforderungen. Das Wasserfallmodell wird meist für große Systementwicklungsprojekte verwendet, bei denen ein System an mehreren Standorten entwickelt wird, wobei die Planorientierung des Wasserfallmodells die Koordinierung der Arbeit erleichtert.

Vorteile der inkrementellen Entwicklung:

Geringere Kosten für Änderungen Die Kosten für die Anpassung an sich ändernde Kundenanforderungen werden reduziert. Der Umfang der Analyse und Dokumentation, die neu erstellt werden muss, ist viel geringer als beim Wasserfallmodell. Häufige Rückmeldungen Es ist einfacher, vom Kunden Rückmeldungen über die geleistete Entwicklungsarbeit zu erhalten. Die Kunden können Demonstrationen der Software kommentieren und sehen, wie viel bereits umgesetzt wurde. Schnellere Lieferung Eine schnellere Lieferung und Bereitstellung von nützlicher Software für den Kunden ist möglich. Die Kunden sind in der Lage, die Software früher zu nutzen und einen Nutzen daraus zu ziehen, als dies bei einem Wasserfallverfahren möglich ist.

Probleme mit inkrementeller Entwicklung (aus der Sicht des Managements):

Der Prozess ist nicht sichtbar Manager benötigen regelmäßige Ergebnisse, um den Fortschritt zu messen. Wenn Systeme schnell entwickelt werden, ist es nicht kosteneffektiv, Dokumente zu erstellen, die jede Version des Systems widerspiegeln. Die Systemstruktur neigt dazu, sich mit dem Hinzufügen neuer Inkremente zu verschlechtern. Wenn nicht viel Zeit und Geld in die Überarbeitung der Software investiert wird, um sie zu verbessern, neigen regelmäßige Änderungen dazu, ihre Struktur zu zerstören. Die Einarbeitung weiterer Softwareänderungen wird zunehmend schwieriger und kostspieliger.

Dieser Ansatz basiert auf einer systematischen Wiederverwendung, bei der Systeme aus bestehenden Komponenten oder COTS-Systemen (Commercial-off-the-shelf) integriert werden.

• Komponentenanalyse;
• Änderung der Anforderungen;
• Systemdesign mit Wiederverwendung;
• Entwicklung und Integration.

Wiederverwendung ist heute der Standardansatz für den Aufbau vieler Arten von Geschäftssystemen.

Typen von Softwarekomponenten:

• Webservices, die nach Servicestandards entwickelt werden und für den Fernaufruf verfügbar sind.
• Sammlungen von Objekten, die als Paket entwickelt werden, um in ein Komponenten-Framework wie .NET oder J2EE integriert zu werden.
• Stand-alone-Systeme von der Stange (COTS), die für den Einsatz in einer bestimmten Umgebung konfiguriert werden.

Reale Software-Prozesse sind ineinandergreifende Abfolgen von technischen, kollaborativen und verwaltungstechnischen Aktivitäten mit dem Gesamtziel der Spezifikation, des Entwurfs, der Implementierung und des Testens eines Software-Systems.

Die vier grundlegenden Prozessaktivitäten der Spezifikation, Entwicklung, Validierung und Evolution sind in verschiedenen Entwicklungsprozessen unterschiedlich organisiert. Im Wasserfallmodell sind sie nacheinander organisiert, während sie bei der inkrementellen Entwicklung ineinander verschachtelt sind.

Softwarespezifikation: Der Prozess, in dem festgelegt wird, welche Dienste benötigt werden und welche Einschränkungen für den Betrieb und die Entwicklung des Systems gelten. Prozess des Requirements Engineering:

• Durchführbarkeitsstudie: Ist es technisch und finanziell machbar, das System zu bauen?
• Anforderungserhebung und -analyse: Was benötigen oder erwarten die Systembeteiligten von dem System?
• Anforderungsspezifikation: Festlegung der Anforderungen im Detail
• Anforderungsvalidierung: Überprüfung der Gültigkeit der Anforderungen

Softwareentwurf und -implementierung Der Prozess der Umsetzung der Systemspezifikation in ein ausführbares System.

• Software-Entwurf: Entwurf einer Software-Struktur, die die Spezifikation realisiert;
• Implementierung: Umsetzung dieser Struktur in ein ausführbares Programm;

Die Aktivitäten des Entwurfs und der Implementierung sind eng miteinander verbunden und können ineinander übergehen. Zu den Entwurfsaktivitäten gehören:

• Architekturentwurf: Identifizierung der Gesamtstruktur des Systems, der Hauptkomponenten (manchmal als Subsysteme oder Module bezeichnet), ihrer Beziehungen und ihrer Verteilung.
• Schnittstellenentwurf: Definition der Schnittstellen zwischen Systemkomponenten.
• Komponentenentwurf: Man nimmt jede Systemkomponente und entwirft, wie sie funktionieren wird.
• Datenbankentwurf: Entwurf der Systemdatenstrukturen und wie diese in einer Datenbank dargestellt werden sollen.

Softwarevalidierung Die Verifikation und Validierung (V & V) soll zeigen, dass ein System mit seiner Spezifikation übereinstimmt und die Anforderungen des Systemkunden erfüllt.

• Validierung: bauen wir das richtige Produkt (das, was der Kunde will)?
• Verifizierung: bauen wir das richtige Produkt?

V & V umfasst Kontroll- und Überprüfungsprozesse und Systemtests. Beim Systemtest wird das System mit Testfällen ausgeführt, die aus der Spezifikation der vom System zu verarbeitenden realen Daten abgeleitet werden. Das Testen ist die am häufigsten verwendete V & V Aktivität und umfasst die folgenden Phasen:

• Entwicklungs- oder Komponententest: Einzelne Komponenten werden unabhängig voneinander getestet; Komponenten können Funktionen oder Objekte oder kohärente Gruppierungen dieser Entitäten sein.
• Systemtest: Test des Systems als Ganzes, wobei der Test von emergenten Eigenschaften besonders wichtig ist.
• Abnahmetest: Test mit Kundendaten, um zu prüfen, ob das System die Anforderungen des Kunden erfüllt.

Softwareentwicklung Software ist von Natur aus flexibel und kann sich ändern. Wenn sich die Anforderungen durch veränderte Geschäftsumstände ändern, muss sich auch die Software, die das Geschäft unterstützt, weiterentwickeln und verändern. obwohl es eine Abgrenzung zwischen Entwicklung und Weiterentwicklung (Wartung) gab, ist dies zunehmend irrelevant, da immer weniger Systeme komplett neu sind.

Änderungen sind bei allen großen Softwareprojekten unvermeidlich.Geschäftsänderungen führen zu neuen und geänderten SystemanforderungenNeue Technologien eröffnen neue Möglichkeiten zur Verbesserung von Implementierungen.Sich ändernde Plattformen erfordern Anwendungsänderungen.Änderungen führen zu Nacharbeiten, so dass die Kosten von Änderungen sowohl Nacharbeiten (z.

Zwei Strategien zur Verringerung der Nacharbeitskosten:

Änderungsvermeidung Der Softwareprozess umfasst Aktivitäten, die mögliche Änderungen vorwegnehmen können, bevor erhebliche Nacharbeit erforderlich ist. Zum Beispiel kann ein Prototypsystem entwickelt werden, um den Kunden einige Schlüsselfunktionen des Systems zu zeigen. Änderungstoleranz Der Prozess ist so konzipiert, dass Änderungen mit relativ geringem Aufwand berücksichtigt werden können, was in der Regel eine Form der schrittweisen Entwicklung beinhaltet. Vorgeschlagene Änderungen können in Inkrementen umgesetzt werden, die noch nicht entwickelt worden sind. Wenn dies nicht möglich ist, muss möglicherweise nur ein einziges Inkrement (ein kleiner Teil des Systems) geändert werden, um die Änderung zu integrieren.

Ein Prototyp ist eine erste Version eines Systems, die zur Demonstration von Konzepten und zum Ausprobieren von Designoptionen verwendet wird. Ein Prototyp kann verwendet werden:

• im Anforderungsentwicklungsprozess zur Unterstützung der Anforderungserhebung und -validierung;
• im Designprozess zur Untersuchung von Optionen und zur Entwicklung eines UI-Designs;
• im Testprozess zur Durchführung von Back-to-Back-Tests.

Vorteile des Prototyping:

• Verbesserte Benutzerfreundlichkeit des Systems.
• Eine bessere Übereinstimmung mit den tatsächlichen Bedürfnissen der Benutzer.
• Verbesserte Designqualität.
• Verbesserte Wartbarkeit.
• Reduzierter Entwicklungsaufwand.

Prototypen können auf Rapid-Prototyping-Sprachen oder -Tools basieren. Sie können das Weglassen von Funktionalität beinhalten:

• Der Prototyp sollte sich auf Bereiche des Produkts konzentrieren, die nicht gut verstanden werden;
• Fehlerkontrolle und -wiederherstellung dürfen im Prototyp nicht enthalten sein;
• Fokus auf funktionale statt auf nicht-funktionale Anforderungen wie Zuverlässigkeit und Sicherheit.

Prototypen sollten nach der Entwicklung verworfen werden, da sie keine gute Basis für ein Produktionssystem sind:

• Es kann unmöglich sein, das System so abzustimmen, dass es nicht-funktionale Anforderungen erfüllt;
• Prototypen sind normalerweise undokumentiert;
• Die Struktur des Prototyps wird normalerweise durch schnelle Änderungen verschlechtert;
• Der Prototyp wird wahrscheinlich nicht den normalen Qualitätsstandards der Organisation entsprechen.

Anstatt das System in einer einzigen Lieferung zu liefern, wird die Entwicklung und Lieferung in Inkremente aufgeteilt, wobei jedes Inkrement einen Teil der erforderlichen Funktionalität liefert.Sobald mit der Entwicklung eines Inkrements begonnen wurde, werden die Anforderungen eingefroren, obwohl die Anforderungen für spätere Inkremente weiter entwickelt werden können.

Vorteile der inkrementellen Lieferung:

• Der Kundennutzen kann mit jedem Inkrement geliefert werden, so dass die Systemfunktionalität früher verfügbar ist.
• Frühe Inkremente dienen als Prototyp, um die Anforderungen für spätere Inkremente zu ermitteln.
• Geringeres Risiko des Scheiterns des Gesamtprojekts.
• Die Systemdienste mit der höchsten Priorität werden in der Regel am häufigsten getestet.

Probleme bei der inkrementellen Bereitstellung:

• Die meisten Systeme erfordern eine Reihe grundlegender Einrichtungen, die von verschiedenen Teilen des Systems verwendet werden. Da die Anforderungen erst dann im Detail definiert werden, wenn ein Inkrement implementiert werden soll, kann es schwierig sein, gemeinsame Einrichtungen zu identifizieren, die von allen Inkrementen benötigt werden.
• Das Wesen iterativer Prozesse besteht darin, dass die Spezifikation in Verbindung mit der Software entwickelt wird. Dies steht jedoch im Widerspruch zum Beschaffungsmodell vieler Unternehmen, bei dem die vollständige Systemspezifikation Teil des Systementwicklungsvertrags ist.

Viele Softwareunternehmen haben sich der Software-Prozessverbesserung zugewandt, um die Qualität ihrer Software zu erhöhen, die Kosten zu senken oder ihre Entwicklungsprozesse zu beschleunigen. Prozessverbesserung bedeutet, bestehende Prozesse zu verstehen und diese Prozesse zu ändern, um die Produktqualität zu erhöhen und/oder Kosten und Entwicklungszeit zu reduzieren.

Prozessreifeansatz Konzentriert sich auf die Verbesserung des Prozess- und Projektmanagements und die Einführung guter Softwareentwicklungspraktiken. Der Grad der Prozessreife spiegelt das Ausmaß wider, in dem gute technische und Managementpraktiken in die organisatorischen Softwareentwicklungsprozesse übernommen wurden. Agiler Ansatz Der Schwerpunkt liegt auf der iterativen Entwicklung und der Reduzierung des Overheads im Softwareprozess. Die wichtigsten Merkmale agiler Methoden sind die schnelle Bereitstellung von Funktionen und die Reaktionsfähigkeit auf sich ändernde Kundenanforderungen.

Prozessverbesserungsaktivitäten bilden einen kontinuierlichen Zyklus mit einer Rückkopplungsschleife:

• Messen Sie ein oder mehrere Attribute des Softwareprozesses oder -produkts. Diese Messungen bilden eine Basislinie, die hilft zu entscheiden, ob Prozessverbesserungen effektiv waren.
• Analysieren Sie den aktuellen Prozess und ermitteln Sie eventuelle Engpässe.
• Ändern Sie den Prozess, um einige der festgestellten Prozessschwächen zu beheben. Diese werden eingeführt und der Zyklus wird fortgesetzt, um Daten über die Wirksamkeit der Änderungen zu sammeln.

Prozessmessung

• Wo immer möglich, sollten quantitative Prozessdaten gesammelt werden.
• Prozessmessungen sollten verwendet werden, um Prozessverbesserungen zu bewerten.
• Messungen können umfassen:
  • Zeit, die für die Ausführung von Prozessaktivitäten benötigt wird, z.z. B. Kalenderzeit oder Aufwand für den Abschluss einer Aktivität oder eines Prozesses.
  • Ressourcen, die für Prozesse oder Aktivitäten benötigt werden, z. B. Gesamtaufwand in Personentagen.
  • Anzahl der Vorkommnisse eines bestimmten Ereignisses, z. B. Anzahl der entdeckten Fehler.

Das SEI-Fähigkeitsreifegradmodell

• Initial: Im Wesentlichen unkontrolliert
• Wiederholbar: Produktmanagementverfahren definiert und verwendet
• Definiert: Prozessmanagementverfahren und -strategien definiert und angewandt
• Verwaltet: Qualitätsmanagementstrategien definiert und angewendet
• Optimierend: Prozessverbesserungsstrategien definiert und angewandt