Spiralmodell

Spiralmodell (Boehm, 1988). Eine Reihe von Missverständnissen beruht auf übermäßigen Vereinfachungen in diesem weit verbreiteten Diagramm (es gibt einige Fehler in diesem Diagramm).[1]

Das Spiralmodell ist ein risikogetriebenes Softwareentwicklungsprozess Modell. Basierend auf den einzigartigen Risikomustern eines bestimmten Projekts führt das Spiralmodell ein Team, um Elemente eines oder mehrerer Prozessmodelle zu übernehmen, wie z. inkrementell, Wasserfall, oder Evolutionsprototyping.

Geschichte

Dieses Modell wurde zuerst von beschrieben von Barry Boehm In seinem 1986er Artikel "ein Spiralmodell der Softwareentwicklung und -verstärkung".[2] 1988 veröffentlichte Boehm ein ähnliches Papier[3] zu einem breiteren Publikum. Diese Papiere führen ein Diagramm ein, das in vielen nachfolgenden Veröffentlichungen über das Spiralmodell reproduziert wurde.

Diese frühen Papiere verwenden den Begriff "Prozessmodell", um sich auf das Spiralmodell sowie auf inkrementelle, Wasserfall, Prototypen und andere Ansätze zu beziehen. Das charakteristische risikogesteuerte Mischung des Spiralmodells der Merkmale anderer Prozessmodelle ist jedoch bereits vorhanden:

[R] ISK-gesteuerte Teilmenge der Spiralmodellschritte ermöglicht es dem Modell, eine geeignete Mischung aus einer spezifikationsorientierten, prototyporientierten, simulationsorientierten, automatisch-transformationsorientierten oder anderen Annäherung an die Softwareentwicklung aufzunehmen.[3]

In späteren Veröffentlichungen,[1] Boehm beschreibt das Spiralmodell als "Prozessmodellgenerator", bei dem Auswahlmöglichkeiten auf der Grundlage der Risiken eines Projekts ein geeignetes Prozessmodell für das Projekt generieren. Daher sind die inkrementellen, Wasserfall-, Prototyp- und anderen Prozessmodelle spezielle Fälle des Spiralmodells, die den Risikomustern bestimmter Projekte entsprechen.

Boehm identifiziert auch eine Reihe von Missverständnissen, die sich aus den Vereinfachungen im ursprünglichen Spiralmodelldiagramm ergeben. Er sagt, die gefährlichsten dieser Missverständnisse seien:

  • dass die Spirale einfach eine Abfolge von Wasserfall -Inkrementen ist;
  • dass alle Projektaktivitäten einer einzigen Spiralsequenz folgen;
  • dass jede Aktivität im Diagramm durchgeführt werden muss und in der gezeigten Reihenfolge.

Diese Missverständnisse entsprechen zwar möglicherweise die Risikomuster einiger weniger Projekte, sie sind jedoch für die meisten Projekte nicht zutreffend.

In einem Bericht des nationalen Forschungsrates[4] Dieses Modell wurde auf Risiken im Zusammenhang mit menschlichen Nutzern erweitert.

Um sie besser von "gefährlichen Spiral-Look-Alikes" zu unterscheiden, listet Boehm sechs Eigenschaften auf, die allen authentischen Anwendungen des Spiralmodells gemeinsam sind.

Die sechs Invarianten des Spiralmodells

Authentische Anwendungen des Spiralmodells werden von Zyklen gesteuert, die immer sechs Eigenschaften aufweisen. Boehm veranschaulicht jeweils ein Beispiel für ein "gefährliches Spiral-Look-Alike", das gegen die Invariante verstößt.[1]

Artefakte gleichzeitig definieren

Die nacheinander definierende Definition der wichtigsten Artefakte für ein Projekt erhöht häufig die Möglichkeit, ein System zu entwickeln, das den Stakeholder -Gewinnbedingungen (Ziele und Einschränkungen) entspricht.

Diese Invariante schließt „gefährliche Spiral-Look-Alike“ -Prozesse aus, die eine Abfolge von inkrementellen Wasserfall in Einstellungen verwenden, in denen die zugrunde liegenden Annahmen des Wasserfallmodells nicht gelten. Boehm listet diese Annahmen wie folgt auf:

  1. Die Anforderungen sind vor der Umsetzung bekannt.
  2. Die Anforderungen haben keine ungelösten Auswirkungen mit hohem Risiko, wie z. B. Risiken aufgrund von Kosten, Zeitplan, Leistung, Sicherheit, Benutzeroberflächen, organisatorischen Auswirkungen usw.
  3. Die Art der Anforderungen wird sich während der Entwicklung oder Entwicklung nicht stark ändern.
  4. Die Anforderungen sind mit allen Erwartungen der wichtigsten Systemstakeholder kompatibel, einschließlich Benutzern, Kunden, Entwicklern, Betreuern und Investoren.
  5. Die richtige Architektur für die Umsetzung der Anforderungen ist gut verstanden.
  6. Es gibt genügend Kalenderzeit, um nacheinander fortzufahren.

In Situationen, in denen diese Annahmen gelten, ist es ein Projektrisiko, die Anforderungen nicht anzugeben und nacheinander fortzufahren. Das Wasserfallmodell wird somit zu einem risikogesteuerten Sonderfall des Spiralmodells.

    Führen Sie in jedem Zyklus vier grundlegende Aktivitäten durch

    Diese Invariante identifiziert die vier Aktivitäten, die in jedem Zyklus des Spiralmodells auftreten müssen:

    1. Betrachten Sie die Gewinnbedingungen aller Erfolgskritischen Stakeholder.
    2. Identifizieren und bewerten Sie alternative Ansätze, um die Gewinnbedingungen zu erfüllen.
    3. Identifizieren und lösen Sie Risiken, die aus dem ausgewählten Ansatz (ES) stammen.
    4. Erhalten Sie die Genehmigung aller Erfolgskritischen Stakeholder sowie die Verpflichtung, den nächsten Zyklus zu verfolgen.

    Projektzyklen, die eine dieser Aktivitäten weglassen oder verkürzt, riskieren die Verschwendung von Anstrengungen, indem sie Optionen verfolgen, die für wichtige Stakeholder inakzeptabel sind oder zu riskant sind.

    Einige "gefährliche Spiral-Look-Alike" -Prozesse verstoßen gegen diese Invariante, indem sie wichtige Stakeholder aus bestimmten sequentiellen Phasen oder Zyklen ausschließen. Beispielsweise werden Systemwartungen und Administratoren möglicherweise nicht zur Teilnahme an der Definition und Entwicklung des Systems eingeladen. Infolgedessen besteht das Risiko, ihre Gewinnbedingungen nicht zu erfüllen.

    Das Risiko bestimmt den Aufwandniveau

    Für jede Projektaktivität (z. B. Anforderungsanalyse, Design, Prototyping, Test) muss das Projektteam entscheiden, wie viel Aufwand ausreicht. In authentischen Spiralprozesszyklen werden diese Entscheidungen getroffen, indem das Gesamtrisiko minimiert wird.

    Zum Beispiel reduziert das Investieren zusätzlicher Zeit, um ein Softwareprodukt zu testen, das Risiko häufig, da der Markt eines schlechten Produkts abgelehnt wird. Eine zusätzliche Testzeit kann jedoch das Risiko aufgrund des frühen Markteintritts eines Wettbewerbers erhöhen. Aus Sicht des Spiralmodells sollte das Testen durchgeführt werden, bis das Gesamtrisiko minimiert ist und nicht weiter.

    Zu den "gefährlichen Spiral-Look-Alikes", die gegen diese Invariante verstoßen, umfassen Evolutionsprozesse, die das Risiko aufgrund von Skalierbarkeitsproblemen ignorieren, und inkrementelle Prozesse, die stark in eine technische Architektur investieren, die neu gestaltet oder ersetzt werden muss, um zukünftige Inkremente des Produkts aufzunehmen.

    Das Risiko bestimmt den Grad der Details

    Für jedes Projektartefakt (z. B. Anforderungsspezifikation, Entwurfsdokument, Testplan) muss das Projektteam entscheiden, wie viel Detail ausreicht. In authentischen Spiralprozesszyklen werden diese Entscheidungen getroffen, indem das Gesamtrisiko minimiert wird.

    Unter Berücksichtigung der Anforderungen als Beispiel sollte das Projekt die Merkmale genau angeben, bei denen das Risiko durch genaue Spezifikation reduziert wird (z. B. Schnittstellen zwischen Hardware und Software, Schnittstellen zwischen Prim- und Subunternehmern). Umgekehrt sollte das Projekt die Merkmale nicht genau angeben, bei denen eine genaue Spezifikation das Risiko erhöht (z. B. grafische Bildschirmlayouts, das Verhalten von Komponenten außerhalb der Person).

    Verwenden Sie Anchor Point -Meilensteine

    Boehms ursprüngliche Beschreibung des Spiralmodells enthielt keine Prozessmeilensteine. In späteren Verfeinerungen führt er drei Meilensteine ​​für Ankerpunkte ein, die als Fortschrittsindikatoren und Verpflichtungspunkte dienen. Diese Meilensteine ​​für Ankerpunkte können durch wichtige Fragen gekennzeichnet werden.

    1. Lebenszyklusziele. Gibt es eine ausreichende Definition eines technischen und Managementansatzes, um die Gewinnbedingungen aller zu befriedigen? Wenn die Stakeholder einverstanden sind, dass die Antwort "Ja" ist, hat das Projekt diesen LCO -Meilenstein geräumt. Andernfalls kann das Projekt aufgegeben werden oder die Stakeholder können sich zu einem anderen Zyklus verpflichten, um zu versuchen, zu "Ja" zu gelangen.
    2. Lebenszyklusarchitektur. Gibt es eine ausreichende Definition des bevorzugten Ansatzes, um die Gewinnbedingungen aller zu erfüllen, und sind alle erhebliche Risiken beseitigt oder gemindert? Wenn die Stakeholder einverstanden sind, dass die Antwort "Ja" ist, hat das Projekt diesen LCA -Meilenstein geräumt. Andernfalls kann das Projekt aufgegeben werden oder die Stakeholder können sich zu einem anderen Zyklus verpflichten, um zu versuchen, zu "Ja" zu gelangen.
    3. Erste Betriebsfähigkeit. Gibt es eine ausreichende Vorbereitung der Software, der Website, der Benutzer, der Betreiber und der Betreuer, um die Gewinnbedingungen aller zu erfüllen, indem das System gestartet wird? Wenn die Stakeholder einverstanden sind, dass die Antwort "Ja" ist, hat das Projekt den IOC -Meilenstein geräumt und wird gestartet. Andernfalls kann das Projekt aufgegeben werden oder die Stakeholder können sich zu einem anderen Zyklus verpflichten, um zu versuchen, zu "Ja" zu gelangen.

    "Gefährliche Spiral-Look-Alikes", die gegen diese Invariante verstoßen, umfassen evolutionäre und inkrementelle Prozesse, die erhebliche Ressourcen für die Implementierung einer Lösung mit einer schlecht definierten Architektur begehen.[Klarstellung erforderlich]

    Die drei Meilensteine ​​der drei Ankerpunkte passen leicht in die Rational einheitlicher Prozess (RUP), wobei LCO die Grenze zwischen Rups Beginn und Ausarbeitungsphasen markiert, lca die Grenze zwischen Ausarbeitung und Bauphasen markiert und die Grenze zwischen Konstruktions- und Übergangsphasen markiert.

    Konzentrieren Sie sich auf das System und seinen Lebenszyklus

    Diese Invariante unterstreicht die Bedeutung des Gesamtsystems und die langfristigen Bedenken, die sich über den gesamten Lebenszyklus erstrecken. Es schließt "gefährliche Spiral-Look-Alikes" aus, die sich zu stark auf die anfängliche Entwicklung des Softwarecode konzentrieren. Diese Prozesse können sich aus den folgenden veröffentlichten Ansätzen für objektorientierte oder strukturierte Softwareanalyse und -gestaltung ergeben und gleichzeitig andere Aspekte der Prozessanforderungen des Projekts vernachlässigen.

    Verweise

    1. ^ a b c Boehm, B (Juli 2000). "Spiralentwicklung: Erfahrung, Prinzipien und Verfeinerungen" (PDF). Sonderbericht. Software Engineering Institute. CMU/SEI-200000-SR-008.
    2. ^ Boehm, b (August 1986). "Ein Spiralmodell der Softwareentwicklung und -verstärkung". ACM Sigsoft Software Engineering Notizen. 11 (4): 14–24. doi:10.1145/12944.12948. S2CID 207165409.
    3. ^ a b Boehm, B (Mai 1988). "Ein Spiralmodell der Softwareentwicklung und -verstärkung" (PDF). IEEE -Computer. 21 (5): 61–72. doi:10.1109/2.59. S2CID 1781829.
    4. ^ Pew, R.W.; Mavor, A.S., Hrsg. (2007). Integration des menschlichen Systems in den Systementwicklungsprozess: Ein neuer Look. Washington, D.C.: National Academy Press. ISBN 978-0-309-10720-4.