Lebenszyklus von Softwaresystemen. Anwendungslebenszyklus Anwendungslebenszyklus

Thema: Klassische und flexible Modelle von LCPP: Definition, Beschreibung, Unterscheidungsmerkmale, die Schrittfolge. Methoden zur Modellwahl des ZhCPP bei der Entwicklung von Software in verschiedenen Fachgebieten.

Informationsquelle https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297

Modelle und Phasen des Softwarelebenszyklus

Unter dem Software-Lebenszyklusmodell wird eine Struktur verstanden, die die Reihenfolge der Ausführung und die Beziehung von Prozessen, Aktionen und Aufgaben während des gesamten Software-Lebenszyklus festlegt. Das Lebenszyklusmodell hängt von den Besonderheiten, dem Umfang und der Komplexität des Projekts und den spezifischen Bedingungen ab, unter denen das System erstellt und betrieben wird.

Der ISO/IEC 12207-Standard bietet dies nicht spezifisches Modell Lebenszyklus und Methoden der Softwareentwicklung. Ihre Bestimmungen sind allen Lebenszyklusmodellen, Methoden und Technologien der Softwareentwicklung gemeinsam. Der Standard beschreibt die Struktur der Softwarelebenszyklusprozesse, spezifiziert jedoch nicht, wie die in diesen Prozessen enthaltenen Aktivitäten und Aufgaben zu implementieren oder durchzuführen sind.

Das Lebenszyklusmodell einer bestimmten Software bestimmt die Art des Prozesses ihrer Erstellung, bei dem es sich um eine Reihe von zeitlich geordneten, miteinander verbundenen und in Phasen (Phasen) vereinigten Arbeiten handelt, deren Implementierung notwendig und ausreichend ist, um Software zu erstellen, die sich erfüllt die angegebenen Anforderungen.

Die Phase (Phase) der Softwareerstellung wird als Teil des Softwareerstellungsprozesses verstanden, der zeitlich begrenzt ist und mit der Freigabe eines bestimmten Produkts (Softwaremodelle, Softwarekomponenten, Dokumentation usw.) endet, das durch die festgelegten Anforderungen bestimmt wird für diese Phase. Aus Gründen der rationellen Planung und Organisation der Arbeit werden die Phasen der Softwareerstellung unterschieden, die mit den festgelegten Ergebnissen enden. Der Software-Lebenszyklus umfasst normalerweise die folgenden Phasen:

1. Bildung von Softwareanforderungen;
2. Design (Entwicklung eines Systemprojekts);
3. Umsetzung (unterteilbar in Teilschritte: Feinkonzeption, Codierung);
4. Testen (kann in eigenständiges und komplexes Testen und Integrieren unterteilt werden);
5. Inbetriebnahme (Implementierung);
6. Betrieb und Instandhaltung;
7. Stilllegung.

Einige Experten führen eine zusätzliche Anfangsphase ein - Machbarkeitsstudie Systeme. Dies bezieht sich auf das Software- und Hardwaresystem, für das Software erstellt, gekauft oder modifiziert wird.

Die Phase der Erstellung von Softwareanforderungen ist eine der wichtigsten und bestimmt zu einem großen Teil (sogar entscheidend!) den Erfolg des gesamten Projekts. Am Anfang dieser Phase steht der Erhalt einer freigegebenen und abgenommenen Systemarchitektur mit Aufnahme von Rahmenvereinbarungen zur Funktionsverteilung zwischen Hard- und Software. Dieses Dokument sollte auch eine Bestätigung der allgemeinen Vorstellung vom Betrieb der Software enthalten, einschließlich der Hauptvereinbarungen zur Verteilung von Funktionen zwischen der Person und dem System.

Die Phase der Bildung von Softwareanforderungen umfasst die folgenden Phasen.

1. Planen Sie die Arbeit vor dem Projekt. Die Hauptaufgaben der Stufe sind die Definition von Entwicklungszielen, vorläufig wirtschaftliche Bewertung Projekt, Erstellung eines Arbeitsplans, Bildung und Ausbildung einer gemeinsamen Arbeitsgruppe.
2. Durchführung einer Erhebung über die Aktivitäten einer automatisierten Organisation (Objekt), in deren Rahmen eine vorläufige Ermittlung der Anforderungen an das zukünftige System durchgeführt wird, Bestimmung der Organisationsstruktur, Bestimmung der Liste der Zielfunktionen der Organisation, Analyse die Verteilung von Funktionen nach Abteilungen und Mitarbeitern, Identifizierung funktionaler Interaktionen zwischen Abteilungen, Informationsflüsse innerhalb von Abteilungen und zwischen ihnen, externe in Bezug auf die Organisation von Objekten und externe Informationseinflüsse, Analyse bestehender Mittel zur Automatisierung der Aktivitäten der Organisation.

Erstellen eines Modells der Tätigkeit einer Organisation (Objekt), das die Verarbeitung von Umfragematerialien und den Aufbau von zwei Arten von Modellen vorsieht:

• ein „AS-IS“ („as is“)-Modell, das den aktuellen Stand der Dinge in der Organisation zum Zeitpunkt der Befragung widerspiegelt und es Ihnen ermöglicht, zu verstehen, wie die Organisation funktioniert, sowie Engpässe zu identifizieren und Verbesserungsvorschläge zu formulieren Lage;
• "TO-BE"-Modell ("wie es sein sollte"), das die Idee neuer Technologien für die Arbeit der Organisation widerspiegelt.

Jedes der Modelle sollte ein vollständiges Funktions- und Informationsmodell der Aktivitäten der Organisation sowie (falls erforderlich) ein Modell enthalten, das die Dynamik des Verhaltens der Organisation beschreibt. Beachten Sie, dass die erstellten Modelle unabhängig davon, ob das Unternehmen ein Informationssystem entwickelt und implementiert, von unabhängiger praktischer Bedeutung sind, da sie zur Schulung von Mitarbeitern und zur Verbesserung der Geschäftsprozesse des Unternehmens verwendet werden können.

Das Ergebnis des Abschlusses der Stufe der Softwareanforderungsbildung sind Softwarespezifikationen, funktionale, technische und Schnittstellenspezifikationen, für die deren Vollständigkeit, Überprüfbarkeit und Realisierbarkeit bestätigt werden.

Die Entwurfsphase umfasst die folgenden Schritte.

1. Entwicklung eines Softwaresystemprojekts. An dieser Stelle wird die Frage „Was soll das zukünftige System leisten?“ beantwortet, nämlich: Architektur des Systems, seine Funktionen, äußere Betriebsbedingungen, Schnittstellen und Funktionsverteilung zwischen Benutzer und System, Anforderungen an Software- und Informationskomponenten, Zusammensetzung der Ausführenden und Fristen werden festgelegt, Entwicklung, Software-Debugging-Plan und Qualitätskontrolle.

   Grundlage des Systemprojekts sind die Modelle des entworfenen Systems, die auf dem „TO-BE“-Modell aufbauen. Das Ergebnis der Entwicklung eines Systemprojekts sollte eine genehmigte und bestätigte Spezifikation von Softwareanforderungen sein: funktionale, technische und Schnittstellenspezifikationen, für die ihre Vollständigkeit, Überprüfbarkeit und Machbarkeit bestätigt werden.

2. Entwicklung eines detaillierten (technischen) Projekts. In dieser Phase wird das eigentliche Softwaredesign durchgeführt, einschließlich des Entwurfs der Systemarchitektur und des detaillierten Designs. Damit ist die Antwort auf die Frage gegeben: "Wie baut man ein System so, dass es die Anforderungen erfüllt?"

Das Ergebnis des detaillierten Designs ist die Entwicklung einer verifizierten Softwarespezifikation, einschließlich:

• Bildung einer Hierarchie von Softwarekomponenten, Schnittstellen zwischen Modulen für Daten und Steuerung;
• Spezifikation jeder Softwarekomponente, Name, Zweck, Annahmen, Größen, Aufrufreihenfolge, Ein- und Ausgabedaten, fehlerhaft Ausgänge, Algorithmen und Logikschaltungen;
• Bildung physikalischer und logischer Datenstrukturen bis auf die Ebene einzelner Felder;
• Entwicklung eines Plans für die Verteilung von Rechenressourcen (Zeit von Zentralprozessoren, Speicher usw.);
• Überprüfung der Vollständigkeit, Konsistenz, Machbarkeit und Gültigkeit der Anforderungen;
• vorläufiger Integrations- und Debuggingplan, Benutzerhandbuch und Akzeptanztestplan.

Der Abschluss der Phase des Feinentwurfs ist die End-to-End-Steuerung des Projekts oder die kritische Blockanalyse des Projekts.

Realisierungsphase – Ausführung der folgenden Arbeiten.

1. Entwicklung einer verifizierten Detailspezifikation für jedes Unterprogramm (ein Block von nicht mehr als 100 Quellbefehlen einer Hochsprache).

   Externe Spezifikationen müssen folgende Informationen enthalten:

   • Modulname - der zum Aufrufen des Moduls verwendete Name wird angegeben (bei einem Modul mit mehreren Eingängen müssen für jeden Eingang separate Angaben gemacht werden);
   • Funktion – definiert die Funktion oder Funktionen, die von dem Modul ausgeführt werden;
   • Liste der an das Modul übergebenen Parameter (Nummer und Reihenfolge);
   • Eingabeparameter - eine genaue Beschreibung aller vom Modul zurückgegebenen Daten (das Verhalten des Moduls unter beliebigen Eingabebedingungen muss bestimmt werden);
   • externe Effekte (Drucken einer Nachricht, Lesen einer Anfrage vom Terminal usw.).
2. Modullogikdesign und Modulprogrammierung (Codierung).
3. Überprüfung der Korrektheit der Module.
4. Modulprüfung.
5. Beschreibung der Datenbank bis auf die Ebene einzelner Parameter, Symbole und Bits.
6. Abnahmetestplan.
7. Benutzerhandbuch.
8. Vorläufiger Plan für Integration und Debugging. Die Inhalte der nachfolgenden Stufen stimmen grundsätzlich mit den entsprechenden Prozessen des Software-Lebenszyklus überein. Im Allgemeinen werden technologische Stufen aufgrund von Überlegungen zur vernünftigen und rationellen Planung und Organisation der Arbeit unterschieden. Eine mögliche Variante der Beziehung und Arbeitsschritte mit den Softwarelebenszyklusprozessen ist in der Abbildung dargestellt.

Reis. eines.

Arten von Software-Lebenszyklusmodellen

Wasserfallmodell (klassischer Lebenszyklus)

Dieses Modell verdankt sein Aussehen W. Royce (1970). Das Modell hat einen anderen Namen - einen Wasserfall (Wasserfall). Die Besonderheit des Modells besteht darin, dass der Übergang zur nächsten Stufe erst erfolgt, nachdem die Arbeiten der vorherigen Stufe vollständig abgeschlossen sind; Rücksendungen zu abgeschlossenen Etappen sind nicht vorgesehen.

Reis. 2.

Die in der Entstehungs- und Analysephase ermittelten Anforderungen an das entwickelte PS werden in Form von TOR streng dokumentiert und für die gesamte Dauer der Projektentwicklung fixiert. Jede Phase endet mit der Veröffentlichung eines vollständigen Dokumentationssatzes (TOR, EP, TP, RP), der ausreicht, um die Entwicklung von einem anderen Entwicklungsteam fortzusetzen. Das Kriterium für die Qualität der Entwicklung bei diesem Ansatz ist die Genauigkeit der Erfüllung der Vorgaben der TOR. Das Hauptaugenmerk der Entwickler liegt auf dem Erreichen optimaler Werte Spezifikationen entwickeltes PS - Leistung, Menge des belegten Speichers usw.

Vorteile Wasserfall-Modell:

• In jeder Phase wird eine vollständige Projektdokumentation erstellt, die die Kriterien für Vollständigkeit und Konsistenz erfüllt.
• Die in logischer Abfolge ausgeführten Arbeitsschritte ermöglichen Ihnen eine zeitliche Planung der Fertigstellung aller Arbeiten und der entsprechenden Kosten.

Beim Bau von PS hat sich der Kaskaden-Ansatz bewährt, bei dem bereits zu Projektbeginn alle Anforderungen vollständig und klar formuliert werden können. Solange dies alles durch Standards und verschiedene staatliche Abnahmekommissionen kontrolliert wird, funktioniert das System gut.

Mängel Wasserfall-Modell:

• die Identifizierung und Beseitigung von Fehlern erfolgt nur in der Testphase, die erheblich verlängert werden kann;
• Reale Projekte erfordern oft eine Abweichung von der Standard-Schrittfolge;
• der Zyklus basiert auf der genauen Formulierung der initialen Anforderungen an die PS, in Wirklichkeit sind zu Beginn des Projekts die Anforderungen des Kunden nur teilweise definiert;
• die Arbeitsergebnisse stehen dem Kunden erst nach Abschluss des Projektes zur Verfügung.

Iteratives Modell des Lebenszyklus von PS

Mit der Zunahme kommerzieller Projekte wurde deutlich, dass es nicht immer möglich ist, das Design des zukünftigen Systems im Detail auszuarbeiten, da sich viele Aspekte seiner Funktionsweise in dynamischen Tätigkeitsbereichen (Business) während der Erstellung des Systems ändern. Es war notwendig, den Entwicklungsprozess zu ändern, um sicherzustellen, dass die erforderlichen Korrekturen nach Abschluss jeder Entwicklungsstufe vorgenommen wurden. So entstand das iterative Modell des Lebenszyklus des PS, das als Modell mit Zwischensteuerung oder als Modell mit zyklischer Wiederholung von Phasen bezeichnet wird.

Reis. 3.

In einem iterativen Modell können Design- und Programmiermängel später beseitigt werden, indem teilweise zum vorherigen Schritt zurückgekehrt wird. Je niedriger die Fehlererkennungsrate, desto teurer die Behebung. Wenn die Kosten für den Aufwand, der erforderlich ist, um Fehler in der Phase des Schreibens des Codes zu erkennen und zu beseitigen, als einer betrachtet werden, sind die Kosten für die Identifizierung und Beseitigung eines Fehlers in der Anforderungsphase 5-10 Mal geringer und die Kosten für die Identifizierung und die Beseitigung eines Fehlers in der Wartungsphase wird 20 mal weniger sein.

Reis. vier.

In einer solchen Situation ist die Phase der Anforderungsformulierung, der Erstellung von Spezifikationen und der Erstellung eines Systemplans von großer Bedeutung. Softwarearchitekten sind persönlich verantwortlich für alle späteren Änderungen an Designentscheidungen. Der Dokumentationsumfang beläuft sich auf tausende Seiten, die Zahl der Abstimmungsgespräche ist enorm. Viele Projekte verlassen die Planungsphase nie und verfallen in die Analyseparalyse. Eine Möglichkeit, solche Situationen zu vermeiden, ist das Breadboarding (Prototyping).

Prototyp entwickeln

Oft kann der Kunde keine Anforderungen an die Eingabe, Verarbeitung oder Ausgabe von Daten für ein zukünftiges Softwareprodukt formulieren. Der Entwickler kann die Eignung des Produkts für das Betriebssystem in Form eines Dialogs mit dem Benutzer oder die Wirksamkeit des Algorithmus anzweifeln. In solchen Fällen empfiehlt sich der Einsatz von Prototyping. Der Hauptzweck des Prototypings besteht darin, die Unsicherheit in den Anforderungen des Kunden zu beseitigen. Modellierung (Prototyping) ist der Prozess der Erstellung eines Modells des erforderlichen Produkts.

Das Modell kann die folgenden Formen annehmen.

1. Papiermockup (handgezeichnetes Diagramm des Mensch-Maschine-Dialogs) oder PC-basiertes Mockup.
2. Ein funktionierendes Layout, das einige der erforderlichen Funktionen implementiert.
3. Ein bestehendes Programm, dessen Eigenschaften verbessert werden müssen.

Wie in der Abbildung dargestellt, basiert das Prototyping auf wiederholten Iterationen, an denen der Kunde und der Entwickler beteiligt sind.

Reis. 5.

Der Handlungsablauf für das Prototyping ist in der Abbildung dargestellt. Das Prototyping beginnt mit der Erhebung und Spezifikation von Anforderungen an das zu erstellende Softwaresystem. Entwickler und Kunde definieren gemeinsam die Ziele der Software, legen fest, welche Anforderungen bekannt sind und welche neu definiert werden sollen. Anschließend wird das Rapid Design durchgeführt. Es konzentriert sich auf Funktionen, die für den Benutzer sichtbar sein sollen. Rapid Design führt zum Aufbau eines Layouts. Das Layout wird vom Kunden bewertet und dient der Klärung der Softwareanforderungen. Iterationen werden fortgesetzt, bis das Layout alle Anforderungen des Kunden aufzeigt und es dem Entwickler ermöglicht, zu verstehen, was zu tun ist.

Der Vorteil des Prototypings ist die Möglichkeit sicherzustellen, dass vollständige Systemanforderungen definiert werden. Layout-Nachteile:

• der Kunde kann das Layout für das Produkt übernehmen;
• Der Entwickler kann das Layout mit dem Produkt verwechseln.

Die Mängel sollten erklärt werden. Wenn der Kunde eine funktionierende Version des PS sieht, merkt er nicht mehr, dass bei der Suche nach einer funktionierenden Version des PS viele Qualitätsprobleme auftreten Begleitkomfort Systeme. Wenn der Entwickler dies dem Kunden mitteilt, kann die Reaktion Empörung sein und die Forderung nach einer schnellen Umsetzung des Layouts in ein funktionierendes Produkt. Dies wirkt sich negativ auf das Management der Softwareentwicklung aus.

Reis. 6.

Andererseits geht der Entwickler oft gewisse Kompromisse ein, um schnell zu einem funktionierenden Layout zu kommen. Beispielsweise können nicht die am besten geeigneten Programmiersprachen oder Betriebssysteme verwendet werden. Für eine einfache Demonstration kann ein ineffizienter (einfacher) Algorithmus verwendet werden. Nach einiger Zeit vergisst der Entwickler die Gründe, warum diese Tools nicht geeignet sind. Dadurch wird eine alles andere als ideal gewählte Option in das System integriert.

Bevor Sie sich andere Software-Lebenszyklusmodelle ansehen, die ersetzt wurden Wasserfall-Modell, sollten wir uns mit den Strategien zum Entwerfen von Softwaresystemen befassen. Es ist die Software-Designstrategie, die weitgehend das Software-Lebenszyklusmodell bestimmt.

Software-Design-Strategien

Es gibt drei Strategien für den Aufbau von Softwaresystemen:

• Single-Pass (oben diskutierte Kaskadenstrategie) – eine lineare Abfolge von Entwurfsschritten;
• inkrementelle Strategie. Zu Beginn des Prozesses werden alle Benutzer- und Systemvoraussetzungen ermittelt, der Rest der Konstruktion erfolgt in einer Reihe von Versionen. Die erste Version implementiert einige der geplanten Funktionen, die nächste Version implementiert zusätzliche Funktionen und so weiter, bis das vollständige System erhalten ist;
• Evolutionäre Strategie. Das System wird auch in einer Reihe von Versionen gebaut, aber nicht alle Anforderungen werden zu Beginn des Prozesses definiert. Anforderungen werden als Ergebnis der Entwicklung von Versionen spezifiziert. Eigenschaften von Softwaredesignstrategien gemäß den Anforderungen des Standards IEEE/EIA 12207 sind in Tabelle 1 dargestellt.

inkrementelles Modell

Das inkrementelle Modell ist ein klassisches Beispiel für eine inkrementelle Designstrategie. Es kombiniert Elemente eines sequentiellen Wasserfallmodells mit einer iterativen Layout-Philosophie (von B. Boehm als Verbesserung vorgeschlagen). Wasserfall-Modell). Jede Zeilenfolge erzeugt dabei ein mitgeliefertes Software-Inkrement. Beispielsweise implementiert eine Textverarbeitungssoftware in der 1. Stufe (Version) die Funktionen grundlegende Verarbeitung Dateien, Bearbeitungs- und Dokumentationsfunktionen; in der 2. Stufe - ausgefeiltere Bearbeitungs- und Dokumentationsfunktionen; in der 3. Stufe - Rechtschreib- und Grammatikprüfung; in der 4. Stufe - Seitenlayoutfunktionen.

Das erste Inkrement ergibt ein Basisprodukt, das die Basisanforderungen umsetzt (viele Nebenanforderungen bleiben jedoch unerfüllt). Der Plan für das nächste Inkrement sieht vor, das Basisprodukt zu modifizieren, um zusätzliche Merkmale und Funktionen bereitzustellen.

Der inkrementelle Prozess ist naturgemäß iterativ, aber im Gegensatz zum Breadboarding liefert das inkrementelle Modell bei jedem Inkrement ein funktionierendes Produkt.

Ein Diagramm eines solchen Software-Lebenszyklusmodells ist in der Abbildung dargestellt. Eine der modernen Implementierungen des inkrementellen Ansatzes ist die extreme Programmierung (die sich auf sehr kleine Funktionsinkremente konzentriert).

Reis. 7.

Spiralmodell des Software-Lebenszyklus

Spiralmodell ist ein klassisches Beispiel für eine evolutionäre Designstrategie. Das Modell (Autor B. Boehm, 1988) basiert auf den besten Eigenschaften des klassischen Lebenszyklus und Prototyping, zu denen ein neues Element hinzugefügt wird – die Risikoanalyse, die in diesen Paradigmen fehlt. Das Modell definiert vier Aktivitäten, die durch die vier Quadranten der Spirale repräsentiert werden.

Reis. acht.

1. Planung ist die Definition von Zielen, Optionen und Einschränkungen.
2. Risikoanalyse – Analyse von Optionen und Risikoerkennung/-auswahl.
3. Engineering ist die nächste Stufe der Produktentwicklung.
4. Bewertung - Bewertung der aktuellen Konstruktionsergebnisse durch den Kunden.

Integrierender Aspekt Spiralmodell ist offensichtlich, wenn man die radiale Abmessung der Wendel betrachtet. Mit jeder Iteration mehr und mehr Vollversionen PS. In der ersten Spirale werden erste Ziele, Optionen und Randbedingungen definiert, Risiken erkannt und analysiert. Zeigt die Risikoanalyse die Unsicherheit der Anforderungen, kommt das im Design-Quadranten eingesetzte Prototyping dem Entwickler und dem Kunden zu Hilfe.

Die Modellierung kann verwendet werden, um problematische und verfeinerte Anforderungen weiter zu identifizieren. Der Kunde bewertet die Engineering-(Design-)Arbeit und macht Änderungsvorschläge (Quadrant Kundenbewertung). Die nächste Phase der Planung und Risikoanalyse basiert auf Kundenvorschlägen. In jedem Zyklus durch die Spirale werden die Ergebnisse der Risikoanalyse in Form von „Weitermachen, nicht weitermachen“ gebildet. Ist das Risiko zu groß, kann das Projekt gestoppt werden.

In den meisten Fällen setzt sich die Spirale fort, wobei jeder Schritt die Entwickler zu einem allgemeineren Systemmodell treibt. Jede Schleife in der Spirale benötigt ein Konstrukt (unterer rechter Quadrant), das durch einen klassischen Lebenszyklus oder Mockup implementiert werden kann. Beachten Sie, dass die Anzahl der Entwicklungsaktivitäten (die im unteren rechten Quadranten auftreten) zunimmt, wenn Sie sich vom Zentrum der Spirale entfernen.

Diese Aktionen sind nummeriert und haben folgenden Inhalt:

1. – anfängliche Anforderungserfassung und Projektplanung;
2. – die gleiche Arbeit, aber basierend auf den Empfehlungen des Kunden;
3. – Risikoanalyse basierend auf anfänglichen Anforderungen;
4. – Risikoanalyse basierend auf Kundenreaktionen;
5. – Übergang zu einem integrierten System;
6. – anfängliches Layout des Systems;
7. - die nächste Ebene des Layouts;
8. – entworfenes System;
9. - Bewertung durch den Kunden.

Vorteile Spiralmodell:

1. am realistischsten (in Form von Evolution) die Entwicklung widerspiegelt Software;
2. ermöglicht es Ihnen, das Risiko in jeder Phase der Entwicklungsentwicklung explizit zu berücksichtigen;
3. enthält einen systematischen Ansatzschritt in der iterativen Entwicklungsstruktur;
4. verwendet Simulation, um Risiken zu reduzieren und das Softwareprodukt zu verbessern.

Mängel Spiralmodell:

• vergleichende Neuheit (es gibt keine ausreichenden Statistiken über die Wirksamkeit des Modells);
• erhöhte Anforderungen an den Kunden;
• Schwierigkeiten bei der Überwachung und Verwaltung der Entwicklungszeit.

Das spiralförmige Entwicklungsprozessmodell ist derzeit am weitesten verbreitet. Seine bekanntesten Varianten sind RUP (Rational Unified Process) von Rational und MSF (Microsoft Solution Framework). Als Modellierungssprache wird UML (Unified Modeling Language) verwendet. Die Erstellung des Systems soll iterativ erfolgen, sich in einer Spirale bewegen und dieselben Phasen durchlaufen, um an jeder Ecke die Eigenschaften des zukünftigen Produkts zu verfeinern. Es scheint, dass jetzt alles in Ordnung ist: Nur das Vorhersehbare wird geplant, das Geplante wird entwickelt, und die Benutzer beginnen sich im Voraus mit dem Produkt vertraut zu machen und haben die Möglichkeit, die erforderlichen Anpassungen vorzunehmen.

Dies erfordert jedoch sehr große Mittel. Wenn es früher möglich war, Gruppen von Spezialisten nach Bedarf zu bilden und aufzulösen, müssen jetzt alle ständig am Projekt teilnehmen: Architekten, Programmierer, Tester, Ausbilder usw. Außerdem müssen die Bemühungen verschiedener Gruppen der Reihe nach synchronisiert werden Designentscheidungen rechtzeitig zu reflektieren und notwendige Änderungen vorzunehmen.

Rationeller einheitlicher Prozess

Rational einheitlicher Prozess(Rational Unified Process, RUP) ist eine der besten Softwareentwicklungsmethoden. Basierend auf der Erfahrung aus vielen erfolgreichen Softwareprojekten ermöglicht Ihnen RUP die Erstellung komplexer Softwaresysteme auf Basis industrieller Entwicklungsmethoden. Die Voraussetzungen für die Entwicklung von RUP stammen aus den frühen 1980er Jahren. bei der Rational Software Corporation. Anfang 2003 erwarb Rational IBM. Eine der Hauptsäulen, auf die sich RUP stützt, ist der Prozess der Modellerstellung mit der Unified Modeling Language (UML).

RUP ist eine der spiralförmigen Softwareentwicklungsmethoden. Die Methodik wird von Rational Software gepflegt und weiterentwickelt. Als Modellierungssprache in gemeinsame Basis knowledge verwendet die Unified Modeling Language (UML). Iterative und inkrementelle Softwareentwicklung in RUP beinhaltet die Aufteilung eines Projekts in mehrere Projekte, die nacheinander ausgeführt werden, und jede Entwicklungsiteration ist klar durch eine Reihe von Zielen definiert, die am Ende der Iteration erreicht werden müssen. Die abschließende Iteration geht davon aus, dass das Zielset der Iteration exakt mit dem vom Kunden des Produkts vorgegebenen Zielset übereinstimmen muss, also alle Anforderungen erfüllt sein müssen.

Der Prozess beinhaltet die Entwicklung von Modellen; eine Iteration des Entwicklungszyklus entspricht eindeutig einer bestimmten Version des Softwaremodells. Jede der Iterationen enthält Steuerelemente Software-Lebenszyklus: Analyse und Design (Modellierung), Implementierung, Integration, Test, Implementierung. In diesem Sinne ist RUP eine Implementierung Spiralmodell, obwohl es ziemlich oft in Form einer Diagrammtabelle dargestellt wird.

Diese Abbildung zeigt zwei Dimensionen: Die horizontale Achse stellt die Zeit dar und zeigt die zeitlichen Aspekte des Prozesslebenszyklus; die vertikale Achse stellt die Disziplinen dar, die die physische Struktur des Prozesses definieren. Sie können sehen, wie sich die Schwerpunkte im Projekt im Laufe der Zeit ändern. Beispielsweise verbringen frühe Iterationen mehr Zeit mit Anforderungen; In späteren Iterationen wird der Implementierung mehr Zeit gewidmet. Die horizontale Achse wird aus Zeitabschnitten gebildet – Iterationen, von denen jede ein unabhängiger Entwicklungszyklus ist; Der Zweck des Zyklus besteht darin, dem Endprodukt eine bestimmte konkrete Verfeinerung zu verleihen, die aus Sicht der Interessengruppen nützlich ist.

Reis. 9.

Entlang der Zeitachse wird der Lebenszyklus in vier Hauptphasen unterteilt.

1. Start (Inception) - die Bildung des Konzepts des Projekts, ein Verständnis dessen, was wir schaffen, eine Vorstellung vom Produkt (Vision), die Entwicklung eines Geschäftsplans (Business Case), die Erstellung von a Prototypprogramm oder Teillösung. Dies ist die Phase des Sammelns von Informationen und der Analyse von Anforderungen, wodurch das Image des Projekts als Ganzes definiert wird. Ziel ist es, Unterstützung und Finanzierung zu erhalten. In der letzten Iteration ist das Ergebnis dieser Phase die Leistungsbeschreibung.
2. Design, Entwicklung (Ausarbeitung) - Klärung des Plans, Verständnis, wie wir ihn erstellen, Design, Planung der erforderlichen Maßnahmen und Ressourcen, Detaillierung der Funktionen. Die Phase endet mit einer lauffähigen Architektur, wenn alle Architekturentscheidungen getroffen und Risiken berücksichtigt sind. Eine ausführbare Architektur ist eine laufende Software, die die Implementierung wichtiger Architekturentscheidungen demonstriert. In der letzten Iteration ist dies ein technisches Projekt.
3. Implementierung, Erstellung des Systems (Construction) ist die Phase der Erweiterung der Funktionalität des in die Architektur eingebetteten Systems. In der letzten Iteration ist dies ein Arbeitsentwurf.
4. Implementierung, Bereitstellung (Übergang). Erstellung der Endversion des Produkts. Phase der Produktimplementierung, Lieferung des Produkts an einen bestimmten Benutzer (Replikation, Lieferung und Schulung).

Die vertikale Achse besteht aus Disziplinen, die jeweils detaillierter beschrieben werden können in Bezug auf die durchgeführten Aufgaben, die dafür verantwortlichen Rollen, die Produkte, die in die Aufgaben eingegeben und während ihrer Ausführung freigegeben werden usw.

Entlang dieser Achse befinden sich die Schlüsseldisziplinen des RUP-Lebenszyklus, die auf Russisch oft als Prozesse bezeichnet werden, obwohl dies aus Sicht dieser Methodik, unterstützt durch Tools von IBM (und / oder Drittanbietern), nicht ganz richtig ist.

1. Geschäftsanalyse und -modellierung ( Geschäftsmodellierung ) bietet die Umsetzung der Prinzipien der Modellierung, um das Geschäft der Organisation zu untersuchen und Wissen darüber zu sammeln, Geschäftsprozesse zu optimieren und Entscheidungen über ihre teilweise oder vollständige Automatisierung zu treffen.
2. Beim Anforderungsmanagement geht es darum, Informationen von Stakeholdern zu sammeln und sie in eine Reihe von Anforderungen umzuwandeln, die den Inhalt des zu entwickelnden Systems definieren und die Erwartungen an das, was das System tun soll, detailliert beschreiben.
3. Analyse und Design (Analyse und Design) umfasst die Verfahren zur Umwandlung von Anforderungen in Zwischenbeschreibungen (Modelle), die darstellen, wie diese Anforderungen implementiert werden sollen.
4. Die Implementierung umfasst die Codeentwicklung, Tests auf Entwicklerebene und die Integration von Komponenten, Subsystemen und dem gesamten System gemäß festgelegten Spezifikationen.
5. Das Testen dient der Beurteilung der Qualität des zu erstellenden Produkts.
6. Die Bereitstellung umfasst die Vorgänge, die bei der Lieferung von Produkten an Kunden und der Bereitstellung des Produkts für Endbenutzer stattfinden.
7. Das Konfigurationsmanagement und Änderungsmanagement (Configuration Management) widmet sich der Synchronisierung von Zwischen- und Endprodukten und der Verwaltung ihrer Entwicklung während des Projekts sowie der Suche nach versteckten Problemen.
8. Das Projektmanagement widmet sich der Projektplanung, dem Risikomanagement, der Überwachung des Projektfortschritts und der kontinuierlichen Bewertung von Schlüsselindikatoren.
9. Management-Umgebung (Environment) umfasst Elemente der Bildung der Entwicklungsumgebung Informationssystem und Unterstützung bei Projektaktivitäten.

Abhängig von den Besonderheiten des Projekts können beliebige IBM Rational-Tools sowie Tools von Drittanbietern verwendet werden. Das RUP empfiehlt die folgenden sechs Praktiken für eine erfolgreiche Projektentwicklung: iterative Entwicklung; Anforderungsmanagement; Verwendung modularer Architekturen; visuelle Modellierung; Qualitätsprüfung; Änderungsverfolgung.

Integraler Bestandteil von RUP sind Artefakte (artefact), Präzedenzfälle (preprecent) und Rollen (role). Artefakte sind einige der Produkte des Projekts, die bei der Arbeit am Endprodukt generiert oder darin verwendet werden. Anwendungsfälle sind Abfolgen von Aktionen, die vom System ausgeführt werden, um ein beobachtbares Ergebnis zu erzielen. Tatsächlich ist jedes Ergebnis der Arbeit eines Einzelnen oder einer Gruppe ein Artefakt, sei es ein Analysedokument, ein Modellelement, eine Codedatei, ein Testskript, eine Fehlerbeschreibung usw. Bestimmte Spezialisten sind dafür verantwortlich Erstellen der einen oder anderen Art von Artefakten. Somit definiert RUP klar die Verantwortlichkeiten – Rollen – jedes Mitglieds des Entwicklungsteams in der einen oder anderen Phase, d. h. wann und wer dieses oder jenes Artefakt erstellen soll. Der gesamte Prozess der Entwicklung eines Softwaresystems wird in RUP als Prozess der Artefakterstellung betrachtet – von anfänglichen Analysedokumenten bis hin zu ausführbaren Modulen, Benutzerhandbüchern usw.

Zur Computerunterstützung von RUP-Prozessen hat IBM eine breite Palette von Tools entwickelt:

• Rational Rose-CASE- visuelles Modellierungswerkzeug Informationssysteme, die Codeelemente generieren können. Eine Sonderausgabe des Produkts - Rational Rose RealTime - ermöglicht es Ihnen, ein ausführbares Modul am Ausgang zu erhalten;
• Rational Requisite Pro ist ein Anforderungsmanagementtool, mit dem Sie Anforderungsänderungen erstellen, strukturieren, priorisieren, verfolgen und steuern können, die in jeder Phase der Entwicklung von Anwendungskomponenten auftreten;
• Rational ClearQuest ist ein Änderungsmanagement- und Fehlerverfolgungsprodukt, das eng in Test- und Anforderungsmanagement-Tools integriert ist und eine einzige Umgebung zum Verknüpfen aller Fehler und Dokumente miteinander bietet.
• Rational SoDA ist ein Produkt zur automatischen Generierung von Projektdokumentationen, mit dem Sie einen Unternehmensstandard für unternehmensinterne Dokumente festlegen können. Es ist auch möglich, die Dokumentation auf bestehende Standards (ISO, CMM) zu bringen;
• Rational Purify, Rational Quantify Rational PureCoverage, Test- und Debugging-Tools;
• Rational Visual Quantify ist ein Tool zur Leistungsmessung für C/C++-, Visual Basic- und Java-Entwickler von Anwendungen und Komponenten. hilft, Engpässe in der Softwareleistung zu identifizieren und zu beseitigen;
• Rational Visual PureCoverage – erkennt automatisch nicht getestete Codebereiche;
• Rational ClearCase ist ein Produkt zur Softwarekonfigurationsverwaltung (Rational's Software Configuration Management, SCM), das die Versionskontrolle aller Projektdokumente ermöglicht. Es kann verwendet werden, um mehrere Versionen von Projekten gleichzeitig zu verwalten und schnell zwischen ihnen zu wechseln. Rational Requisite Pro unterstützt Aktualisierungen und verfolgt Änderungen in den Anforderungen für das Entwicklungsteam;
• SQA TeamTest-Tool Testautomatisierung;
• Rational TestManager ist ein Testmanagementsystem, das alle testbezogenen Tools, Artefakte, Skripte und Daten zusammenführt;
• Rational Robot – ein Tool zum Erstellen, Ändern und automatischen Ausführen von Tests;
• SiteLoad, SiteCheck - Tools zum Testen von Websites auf Leistung und defekte Links;
• Rational PerformanceStudio - Messen und prognostizieren Sie die Leistungsmerkmale von Systemen.

Diese Produktpalette wird ständig verbessert und erweitert. Beispielsweise ist das jüngste Produkt IBM Rational Software Architect (RSA) Teil der IBM Software Development Platform, einer Reihe von Tools, die den Lebenszyklus der Softwaresystementwicklung unterstützen. Das IBM Rational Software Architect-Produkt wurde entwickelt, um Modelle von Softwaresystemen zu erstellen, die unter Verwendung der vereinheitlichten Modellierungssprache UML 2.0 entwickelt werden, hauptsächlich Modelle der Architektur der zu entwickelnden Anwendung. RSA kombiniert jedoch die Funktionalität von Softwareprodukten wie Rational Application Developer, Rational Web Developer und Rational Software Modeler, wodurch Architekten und Analysten verschiedene Ansichten des zu entwickelnden Informationssystems mit der Sprache UML 2.0 erstellen und Entwickler die Entwicklung durchführen können J2EE, XML, Webservices etc.

Gemäß den Prinzipien von RUP ermöglicht Ihnen Rational Software Architect, die erforderlichen Modelle innerhalb der Arbeitsabläufe von Disziplinen zu erstellen, wie z. B.:

• Geschäftsanalyse und -modellierung (Geschäftsmodellierung);
• Anforderungsmanagement (Anforderungen);
• Analyse und Design (Analyse und Design);
• Umsetzung (Implementierung).

Darüber hinaus unterstützt Rational Software Architect die modellgetriebene Entwicklungstechnologie (MDD), mit der Sie Software auf verschiedenen Abstraktionsebenen mit Rückverfolgbarkeit modellieren können.

MSF (Microsoft Solution Framework)

Um das Beste aus IT-Projekten herauszuholen, veröffentlichte Microsoft 1994 eine Reihe von Richtlinien für das effektive Entwerfen, Entwickeln, Implementieren und Warten von Lösungen, die auf seiner Technologie aufbauen. Dieses Wissen basiert auf der Erfahrung, die Microsoft bei der Arbeit an großen Softwareentwicklungs- und Wartungsprojekten gesammelt hat, der Erfahrung von Microsoft-Beratern und dem Besten, was die IT-Branche bisher gesammelt hat. All dies wird in Form von zwei zusammenhängenden und gut komplementären Wissensbereichen präsentiert: Microsoft Solutions Framework (MSF) und Microsoft Operations Framework (MOF).

Es sei darauf hingewiesen, dass Microsoft Methoden entwickelt hat, die auf den allgemeinen MSF-Methoden für angewandte und spezialisierte Anwendungen basieren. Darüber hinaus zertifiziert Microsoft Experten speziell für angewandtes Wissen in der Anwendung von MSF (z. B. MCTS 74-131-Zertifizierung für Expertise in Projektmanagementmethodik). Bevor Sie sich mit MSF-Methoden vertraut machen, müssen Sie zuerst bestimmen, welche Anwendung von MSF Sie im Sinn haben.

Die beliebtesten Anwendungsvarianten von MSF, die von Microsoft entwickelt wurden, sind:

• Methodik zur Umsetzung von Lösungen im Bereich Projektmanagement;
• IT-Projektmanagementmethodik basierend auf MSF- und Agile-Methoden.

Die Bedeutung angewandter Varianten von MSF wird dadurch unterstrichen, dass in der „reinen Version“ die MSF-Methodik selbst von Microsoft in seinen IT-Projekten nicht verwendet wird. Microsoft Consulting Services-Projekte verwenden eine hybride Methodik zwischen MSF und Agile. Trotz der äußerlichen signifikanten Unterschiede zwischen den von Microsoft-Experten entwickelten MSF-Versionen bleibt die Basis der MSF-Methoden für sie gleich und spiegelt gemeinsame methodische Ansätze für das iterative Projektmanagement wider.

MOF wurde entwickelt, um Organisationen, die unternehmenskritische IT-Lösungen auf der Grundlage von Microsoft-Produkten und -Technologien entwickeln, technische Anleitungen zur Erreichung ihrer Zuverlässigkeit, Verfügbarkeit, Begleitkomfort(Unterstützbarkeit) und Verwaltbarkeit (Verwaltbarkeit). MOF behandelt Fragen im Zusammenhang mit der Organisation von Personal und Prozessen; Technologien und Management unter Bedingungen komplexer (komplexer), verteilter (verteilter) und heterogener (heterogener) IT-Umgebungen. MOF basiert auf Best Practices, die in der IT Infrastructure Library (ITIL) gesammelt wurden, die von der Central Computer and Telecommunications Agency, einer britischen Regierungsbehörde, zusammengestellt wurde.

Das Erstellen einer Geschäftslösung innerhalb der zugewiesenen Zeit und des Budgets erfordert eine bewährte methodischer Rahmen. MSF bietet bewährte Methoden für die Planung, Gestaltung, Entwicklung und Implementierung erfolgreicher IT-Lösungen. Mit seiner Flexibilität, Skalierbarkeit und dem Fehlen starrer Richtlinien ist MSF in der Lage, die Anforderungen von Organisationen oder Projektteams jeder Größe zu erfüllen. Die MSF-Methodik besteht aus Prinzipien, Modellen und Disziplinen für das Management von Personal, Prozessen, technologischen Elementen und Fragen im Zusammenhang mit all diesen Faktoren, die für die meisten Projekte typisch sind. MSF besteht aus zwei Modellen und drei Disziplinen. Sie werden in 5 Whitepapers detailliert beschrieben. Es ist besser, MSF mit Modellen (Projektteammodell, Prozessmodell) zu studieren und dann mit Disziplinen (Projektmanagementdisziplin, Risikomanagementdisziplin, Schulungsmanagementdisziplin) fortzufahren.

Das MSF-Vorgehensmodell stellt eine allgemeine Methodik für die Entwicklung und Implementierung von IT-Lösungen dar. Die Besonderheit dieses Modells besteht darin, dass es aufgrund seiner Flexibilität und des Fehlens starr vorgegebener Verfahren bei der Entwicklung verschiedenster IT-Projekte eingesetzt werden kann. Dieses Modell kombiniert die Eigenschaften zweier Standardproduktionsmodelle: Kaskade (Wasserfall) und Spirale (Spirale). Das Prozessmodell in MSF 3.0 war weiter innovativ: Es deckt den gesamten Lebenszyklus einer Lösung ab, vom Startpunkt bis zur Implementierung. Dieser Ansatz hilft Projektteams, sich auf den geschäftlichen Wert der Lösung zu konzentrieren, da dieser Wert erst dann real wird, wenn die Implementierung abgeschlossen ist und das Produkt verwendet wird.

Der MSF-Prozess konzentriert sich auf "Meilensteine" - die Schlüsselpunkte des Projekts, die die Errungenschaft innerhalb seines Rahmens eines signifikanten (Zwischen- oder End-) Ergebnisses charakterisieren. Dieses Ergebnis kann ausgewertet und analysiert werden, was die Beantwortung der Fragen bedeutet: „Ist das Projektteam zu einem eindeutigen Verständnis der Ziele und des Umfangs des Projekts gelangt?“, „Ist der Aktionsplan ausreichend vorbereitet?“, „Trifft das Produkt der genehmigten Spezifikation?", " Erfüllt die Lösung die Bedürfnisse des Kunden? usw.

Das MSF-Vorgehensmodell berücksichtigt ständig wechselnde Projektanforderungen. Es geht davon aus, dass die Entwicklung einer Lösung aus kurzen Zyklen bestehen sollte, die eine fortschreitende Bewegung von den einfachsten Versionen der Lösung bis zu ihrer endgültigen Form schaffen.

Die Merkmale des MSF-Prozessmodells sind:

• ein Phasen- und Meilensteinansatz;
• iterativer Ansatz;
• ein integrierter Ansatz zur Erstellung und Implementierung von Lösungen.

Das Prozessmodell umfasst folgende Hauptphasen des Entwicklungsprozesses:

• Konzeptentwicklung (Envisioning);
• Planung (Planung);
• Entwicklung (Entwicklung);
• Stabilisierung (Stabilisierung);
• Implementierung (Bereitstellen).

Darüber hinaus gibt es eine Vielzahl von Zwischenmeilensteinen, die das Erreichen bestimmter Fortschritte im Projektverlauf anzeigen und große Arbeitsabschnitte in kleinere, beobachtbare Abschnitte unterteilen. Für jede Phase des Prozessmodells definiert MSF:

• was (welche Artefakte) ist das Ergebnis dieser Phase;
• woran jeder der Rollencluster in dieser Phase arbeitet.

Innerhalb von MSF werden Code, Dokumentation, Entwürfe, Pläne und andere Arbeitsmaterialien normalerweise iterativ erstellt. MSF empfiehlt, dass Sie mit der Entwicklung einer Lösung beginnen, indem Sie ihre Kernfunktionalität erstellen, testen und bereitstellen. Dann werden der Lösung immer mehr Funktionen hinzugefügt. Diese Strategie wird Versionierungsstrategie genannt. Während für kleinere Projekte eine einzelne Version ausreichen kann, sollten Sie die Gelegenheit nicht verpassen, mehrere Versionen für eine einzelne Lösung zu erstellen. Mit der Erstellung neuer Versionen entwickelt sich die Funktionalität der Lösung weiter.

Eine iterative Herangehensweise an den Entwicklungsprozess erfordert den Einsatz einer flexiblen Dokumentation. Lebende Dokumente sollten sich ändern, wenn sich das Projekt weiterentwickelt, zusammen mit Änderungen in den Anforderungen für das Endprodukt. Das MSF bietet eine Reihe von Standarddokumentvorlagen, die Artefakte jeder Phase der Produktentwicklung sind und zur Planung und Steuerung des Entwicklungsprozesses verwendet werden können.

Eine Lösung hat keinen geschäftlichen Wert, bis sie implementiert ist. Aus diesem Grund beinhaltet das MSF-Prozessmodell den gesamten Lebenszyklus von der Erstellung einer Lösung, einschließlich ihrer Implementierung, bis zu dem Moment, in dem die Lösung beginnt, Wert zu liefern.

in der Elektrotechnik). Dieser Standard definiert die Struktur des Lebenszyklus, der die Prozesse, Aktivitäten und Aufgaben enthält, die während der Erstellung des PS durchgeführt werden müssen.

In diesem PS-Standard (bzw Software) ist definiert als eine Reihe von Computerprogrammen, Verfahren und möglicherweise zugehörigen Dokumentationen und Daten. Der Prozess ist definiert als eine Reihe zusammenhängender Aktionen, die einige Eingabedaten in Ausgabedaten umwandeln (G. Myers nennt dies Datenübersetzung). Jeder Prozess ist durch bestimmte Aufgaben und Methoden zu deren Lösung gekennzeichnet. Jeder Prozess ist wiederum in eine Reihe von Aktionen unterteilt, und jede Aktion ist in eine Reihe von Aufgaben unterteilt. Jeder Prozess, jede Aktion oder Aufgabe wird nach Bedarf von einem anderen Prozess initiiert und ausgeführt, und es gibt keine vorbestimmten Ausführungssequenzen (natürlich unter Beibehaltung der Eingangsdatenverbindungen).

Es sei darauf hingewiesen, dass in der Sowjetunion und dann in Russland die Erstellung von Software (SW) zunächst in den 70er Jahren des letzten Jahrhunderts durch die GOST ESPD-Standards geregelt wurde ( einheitliches System Softwaredokumentation - eine Reihe von GOST 19.XXX), die sich auf eine Klasse relativ einfacher, kleinvolumiger Programme konzentrierten, die von einzelnen Programmierern erstellt wurden. Derzeit sind diese Standards konzeptionell und formal veraltet, ihre Gültigkeit abgelaufen und ihre Verwendung nicht sachgerecht.

Die Prozesse zur Erstellung automatisierter Systeme (AS), zu denen auch Software gehört, werden durch die Standards GOST 34.601-90 "Informationstechnologie. Eine Reihe von Standards für automatisierte Systeme. Phasen der Erstellung", GOST 34.602-89 "Informationstechnologie. A Reihe von Standards für automatisierte Systeme. Technische Aufgabe für die Erstellung eines automatisierten Systems" und GOST 34.603-92 "Informationstechnologie. Arten von Tests von automatisierten Systemen". Viele Bestimmungen dieser Standards sind jedoch veraltet, während andere nicht genug reflektiert sind, um für ernsthafte Projekte zur Erstellung von PS verwendet zu werden. Daher ist es ratsam, moderne internationale Standards bei inländischen Entwicklungen zu verwenden.

Entsprechend ISO-Norm/ IEC 12207 werden alle Software-Lebenszyklusprozesse in drei Gruppen eingeteilt (Bild 5.1).

Reis. 5.1.

In den Gruppen sind fünf Hauptprozesse definiert: Beschaffung, Lieferung, Entwicklung, Betrieb und Instandhaltung. Acht Teilprozesse stellen die Ausführung der Hauptprozesse sicher, nämlich Dokumentation, Konfigurationsmanagement, Qualitätssicherung, Verifizierung, Validierung, gemeinsame Bewertung, Audit, Problemlösung. Die vier organisatorischen Prozesse bieten Governance, Infrastrukturaufbau, Verbesserung und Lernen.

5.2. Die Hauptprozesse des Lebenszyklus des PS

Der Beschaffungsprozess besteht aus den Tätigkeiten und Aufgaben des Kunden, der die Software kauft. Dieser Prozess umfasst die folgenden Schritte:

1. Akquisitionsinitiierung;
2. Erstellung von Bewerbungsvorschlägen;
3. Vorbereitung und Anpassung des Vertrages;
4. Überwachung der Aktivitäten des Lieferanten;
5. Abnahme und Fertigstellung der Arbeiten.

Die Akquisitionsinitiierung umfasst die folgenden Aufgaben:

1. Ermittlung seiner Bedürfnisse beim Erwerb, der Entwicklung oder Verbesserung des Systems, der Softwareprodukte oder der Dienstleistungen durch den Kunden;
2. Treffen einer Entscheidung bezüglich des Erwerbs, der Entwicklung oder Verbesserung bestehender Software;
3. Überprüfung der Verfügbarkeit der erforderlichen Dokumentation, Garantien, Zertifikate, Lizenzen und Support beim Kauf eines Softwareprodukts;
4. Vorbereitung und Genehmigung des Akquisitionsplans, einschließlich Systemanforderungen, Vertragsart, Verantwortlichkeiten der Parteien usw.

Gebote müssen enthalten:

1. System Anforderungen;
2. Liste von Softwareprodukten;
3. Erwerbs- und Vertragsbedingungen;
4. technische Einschränkungen (z. B. in der Betriebsumgebung des Systems).

Bei einer Ausschreibung werden Angebote an einen ausgewählten Lieferanten oder mehrere Lieferanten gesendet. Ein Lieferant ist eine Organisation, die mit einem Kunden einen Vertrag über die Lieferung eines Systems, einer Software oder einer Softwaredienstleistung zu den im Vertrag festgelegten Bedingungen abschließt.

Die Vorbereitung und Anpassung des Vertrages umfasst folgende Aufgaben:

1. Festlegung des Verfahrens zur Auswahl eines Lieferanten durch den Kunden, einschließlich Kriterien zur Bewertung der Vorschläge möglicher Lieferanten;
2. Auswahl eines bestimmten Lieferanten auf der Grundlage der Analyse von Angeboten;
3. Vorbereitung und Abschluss Lieferantenverträge;
4. (falls erforderlich) Änderungen am Vertrag im Zuge seiner Durchführung vorzunehmen.

Die Aktivitäten des Lieferanten werden gemäß den in den gemeinsamen Bewertungs- und Auditprozessen festgelegten Maßnahmen überwacht. Während des Abnahmeprozesses werden die notwendigen Prüfungen vorbereitet und durchgeführt. Die Vertragserfüllung erfolgt bei Erfüllung aller Abnahmebedingungen.

Der Lieferprozess umfasst die Aktivitäten und Aufgaben, die von einem Anbieter ausgeführt werden, der einen Kunden mit einem Softwareprodukt oder einer Dienstleistung beliefert. Dieser Prozess umfasst die folgenden Schritte:

1. Lieferinitiierung;
2. Vorbereitung einer Antwort auf Angebote;
3. Vorbereitung des Vertrages;
4. Auftragsarbeitsplanung;
5. Ausführung und Kontrolle von Auftragsarbeiten und deren Bewertung;
6. Lieferung und Fertigstellung der Arbeiten.

Die Anbahnung der Lieferung besteht in der Prüfung der Angebotsvorschläge durch den Lieferanten und der Entscheidung, ob er den gestellten Anforderungen und Bedingungen zustimmt oder eigene anbietet (vereinbart). Die Planung umfasst folgende Aufgaben:

1. Entscheidung des Lieferanten über die Durchführung von Arbeiten allein oder unter Einbeziehung eines Subunternehmers;
2. Entwicklung eines Projektmanagementplans durch den Lieferanten organisatorische Struktur Projekt, Aufgabenteilung, technische Anforderungen zur Entwicklungsumgebung und -ressourcen, Verwaltung von Unterauftragnehmern etc.

Der Entwicklungsprozess sieht die Tätigkeiten und Aufgaben des Entwicklers vor und umfasst die Arbeit zur Erstellung von Software und ihren Komponenten gemäß den festgelegten Anforderungen. Dies umfasst die Ausführung der Konstruktions- und Betriebsdokumentation, die Vorbereitung der für die Leistungsprüfung erforderlichen Materialien und Qualität von Softwareprodukten, Materialien, die für die Organisation der Mitarbeiterschulung erforderlich sind usw.

Der Entwicklungsprozess umfasst die folgenden Schritte:

1. Vorarbeit;
2. Analyse der Anforderungen an das System;
3. Design der Systemarchitektur;
4. Analyse von Anforderungen an Software;
5. Design von Softwarearchitekturen;
6. detailliertes Softwaredesign;
7. Softwarecodierung und -prüfung;
8. Softwareintegration;
9. Software-Qualifikationstests;
10. System Integration;
11. Eignungsprüfung des Systems;
12. Software Installation;
13. Softwareakzeptanz.

Die Vorarbeiten beginnen mit der Auswahl eines Software-Lebenszyklusmodells, das der Größe, Bedeutung und Komplexität des Projekts angemessen ist. Die Aktivitäten und Aufgaben des Entwicklungsprozesses sollten mit dem gewählten Modell übereinstimmen. Der Entwickler muss die mit dem Kunden vereinbarten Standards, Methoden und Methoden auswählen, an die Bedingungen des Projekts anpassen und anwenden. Entwicklungswerkzeuge, sowie einen Arbeitsplan erstellen.

Die Analyse der Anforderungen an das System umfasst die Bestimmung seiner Funktionalität, kundenspezifische Anforderungen, Anforderungen an Zuverlässigkeit, Sicherheit, Anforderungen an externe Schnittstellen, Performance etc. Systemanforderungen werden anhand von Machbarkeitskriterien und Verifizierbarkeit während des Tests bewertet.

Das Design der Systemarchitektur besteht darin, die Komponenten ihrer Ausrüstung (Hardware), Software und Operationen zu bestimmen, die vom Personal ausgeführt werden, das das System bedient. Die Architektur des Systems muss den Systemanforderungen und anerkannten Designstandards und -praktiken entsprechen.

Bei der Analyse der Softwareanforderungen werden die folgenden Merkmale für jede Softwarekomponente bestimmt:

1. Funktionalität, einschließlich Leistungsmerkmale und Betriebsumgebung der Komponente;
2. externe Schnittstellen;
3. Zuverlässigkeits- und Sicherheitsspezifikationen;
4. ergonomische Anforderungen;
5. Anforderungen an die verwendeten Daten;
6. Installations- und Abnahmeanforderungen;
7. Anforderungen an die Benutzerdokumentation;
8. Anforderungen an Betrieb und Wartung.

Die Softwareanforderungen werden anhand der Kriterien Erfüllung der Anforderungen an das Gesamtsystem, Realisierbarkeit und Überprüfbarkeit im Test bewertet.

Das Softwarearchitekturdesign umfasst die folgenden Aufgaben für jede Softwarekomponente:

1. Transformation von Softwareanforderungen in eine Architektur, die die Struktur der Software und die Zusammensetzung ihrer Komponenten auf hohem Niveau definiert;
2. Entwicklung und Dokumentation von Programmschnittstellen für Software und Datenbanken (DB);
3. Entwicklung einer vorläufigen Version der Benutzerdokumentation;
4. Entwicklung und Dokumentation von Voraussetzungen für Tests und Software-Integrationsplan.

Das detaillierte Softwaredesign umfasst die folgenden Aufgaben:

1. Beschreibung von Softwarekomponenten und Schnittstellen zwischen ihnen auf einer niedrigeren Ebene, ausreichend für späteres Codieren und Testen;
2. Entwicklung und Dokumentation eines detaillierten Datenbankdesigns;
3. Aktualisierung (falls erforderlich) der Benutzerdokumentation;
4. Entwicklung und Dokumentation von Testanforderungen und eines Plans zum Testen von Softwarekomponenten;

Das Programmieren und Testen von Software umfasst die folgenden Aufgaben:

1. Kodierung und Dokumentation jeder Komponente der Software und Datenbank sowie Vorbereitung einer Reihe von Testverfahren und Daten zu deren Test;
2. Testen jeder Komponente der Software und Datenbank auf Übereinstimmung mit den Anforderungen an sie, gefolgt von Dokumentation der Testergebnisse;
3. Aktualisierung der Dokumentation (falls erforderlich);
4. Aktualisierung des Softwareintegrationsplans.

Die Softwareintegration sieht die Zusammenstellung der entwickelten Softwarekomponenten gemäß dem Integrations- und Testplan für die aggregierten Komponenten vor. Für jede der aggregierten Komponenten werden Testsuiten und Testverfahren entwickelt, um jede der Kompetenzen in anschließenden Ringversuchen zu testen. Eine Qualifikationsanforderung ist eine Reihe von Kriterien oder Bedingungen, die erfüllt werden müssen, um sich zu qualifizieren. Software als konform mit seinen Spezifikationen und bereit für den Einsatz im Feld.

Die Eignungsprüfung von Software wird vom Entwickler im Beisein des Kunden durchgeführt (

Der Betriebsprozess umfasst die Tätigkeiten und Aufgaben der Organisation des Betreibers, der die Anlage betreibt. Der Betriebsprozess umfasst die folgenden Schritte.

1. Vorbereitende Arbeiten, die die Durchführung folgender Aufgaben durch den Bediener umfassen:

   1. Planung von Aktivitäten und Arbeiten, die während des Betriebs durchgeführt werden, und Festlegung von Betriebsstandards;
   2. Festlegung von Verfahren zur Lokalisierung und Lösung von Problemen, die während des Betriebs auftreten.
2. Betriebstests werden für jede nächste Ausgabe des Softwareprodukts durchgeführt, wonach diese Ausgabe in den Betrieb überführt wird.
3. Der eigentliche Betrieb des Systems, der in der dafür vorgesehenen Umgebung gemäß der Benutzerdokumentation durchgeführt wird.
4. Analyse von Problemen und Änderungswünschen der Software (Analyse von Meldungen über ein aufgetretenes Problem oder einen Änderungswunsch, Bewertung des Ausmaßes, Änderungskosten, resultierende Wirkung, Bewertung der Machbarkeit der Änderung);
5. Softwaremodifikation (Änderungen an Softwareproduktkomponenten und Dokumentation gemäß den Regeln des Entwicklungsprozesses);
6. Verifizierung und Akzeptanz (in Bezug auf die Integrität des zu modifizierenden Systems);
7. Übertragung von Software in eine andere Umgebung (Konvertierung von Programmen und Daten, paralleler Betrieb von Software in der alten und neuen Umgebung für einen bestimmten Zeitraum);
8. Außerbetriebnahme der Software durch Entscheidung des Kunden unter Beteiligung von Betreiber, Wartungsdienst und Anwendern. Gleichzeitig unterliegen Softwareprodukte und Dokumentationen der vertragsgemäßen Archivierung.

Software-Lebenszyklus - ein Zeitraum, der mit dem Zeitpunkt beginnt, an dem eine Entscheidung über die Notwendigkeit der Erstellung eines Softwareprodukts getroffen wird, und mit dem Zeitpunkt endet, an dem es vollständig aus dem Betrieb genommen wird.

Softwarelebenszyklusprozesse:

Basic,

Hilfs,

Organisatorisch.

Hauptsächlich:

1. Erwerb - Handlungen und Aufgaben des Kunden, der die Software kauft;

2. Lieferung - die Aktivitäten und Aufgaben des Lieferanten, der dem Kunden ein Softwareprodukt oder eine Dienstleistung liefert;

3. Entwicklung - vom Entwickler durchgeführte Aktionen und Aufgaben: Softwareentwicklung, Ausführung von Design- und Betriebsdokumentationen, Vorbereitung von Tests und Lehrmaterial;

4. Betrieb - Aktionen und Aufgaben des Betreibers der Organisation, die das System betreibt;

5. Wartung – Vornehmen von Änderungen an der Software, um Fehler zu beheben, die Leistung zu verbessern oder sich an sich ändernde Betriebsbedingungen oder Anforderungen anzupassen.

Hilfs:

1. Dokumentation – eine formalisierte Beschreibung von Informationen, die während des Software-Lebenszyklus erstellt wurden;

2. Konfigurationsmanagement – ​​die Anwendung administrativer und technischer Verfahren während des gesamten Softwarelebenszyklus, um den Zustand von Softwarekomponenten zu bestimmen und ihre Änderungen zu verwalten;

3. Qualitätssicherung – Gewährleistung, dass die Software und ihre Lebenszyklusprozesse den festgelegten Anforderungen und genehmigten Plänen entsprechen;

4. Verifizierung - Feststellung, dass Softwareprodukte die Anforderungen oder Bedingungen aufgrund früherer Aktionen vollständig erfüllen;

5. Zertifizierung - Feststellung der Vollständigkeit der Übereinstimmung der spezifizierten Anforderungen und des erstellten Systems mit ihrem spezifischen funktionalen Zweck;

6. Gemeinsame Bewertung - Bewertung des Arbeitsstands des Projekts: Kontrolle der Planung und Verwaltung von Ressourcen, Personal, Ausrüstung, Werkzeugen;

7. Audit – Feststellung der Einhaltung der Anforderungen, Pläne und Bedingungen des Vertrages;

8. Problemlösung - Analyse und Lösung von Problemen, unabhängig von ihrer Herkunft oder Quelle, die während der Entwicklung, des Betriebs, der Wartung oder anderer Prozesse entdeckt werden.

Organisatorisch:

1. Management – ​​Aktionen und Aufgaben, die von jeder Partei durchgeführt werden können, die ihre Prozesse verwaltet;

2. Schaffung von Infrastruktur - Auswahl und Wartung von Technologie, Standards und Tools, Auswahl und Installation von Hardware und Software, die zur Entwicklung, zum Betrieb oder zur Wartung von Software verwendet werden;

3. Verbesserung - Bewertung, Messung, Kontrolle und Verbesserung der Lebenszyklusprozesse;

4. Ausbildung - Erstausbildung und anschließende kontinuierliche berufliche Entwicklung des Personals.

Im Jahr 2002 wurde der Standard für Systemlebenszyklusprozesse (ISO/IEC 15288 Systemlebenszyklusprozesse) veröffentlicht. An der Entwicklung des Standards waren Experten aus verschiedenen Bereichen beteiligt: ​​Systems Engineering, Programmierung, Qualitätsmanagement, durch Humanressourcen, Sicherheit usw. Praktische Erfahrungen bei der Erstellung von Systemen in staatlichen, kommerziellen, militärischen und akademischen Organisationen wurden berücksichtigt. Der Standard ist auf eine breite Klasse von Systemen anwendbar, sein Hauptzweck besteht jedoch darin, die Erstellung computergestützter Systeme zu unterstützen.

Gemäß der Reihe ISO/IEC 15288 sollten folgende Prozessgruppen in die Lebenszyklusstruktur aufgenommen werden:

1. Vertragliche Abläufe:

Akquisition (Inhouse-Lösungen oder externe Anbieterlösungen);

Lieferung (interne Lösungen oder externe Lieferantenlösungen);

2. Unternehmensprozesse:

Kontrolle Umgebung Unternehmen;

Investitionsmanagement;

IP-Lebenszyklusmanagement;

Resourcenmanagement;

Qualitätskontrolle;

3. Designprozesse:

Projektplanung;

Projektbewertung;

Projekt Kontrolle;

Risikomanagement;

Konfigurationsmanagement;

Informationsflussmanagement;

Entscheidungen treffen.

4. Technische Prozesse:

Definition von Anforderungen;

Anforderungsanalyse;

Architekturentwicklung;

Implementierung;

Integration;

Überprüfung;

Übergang;

Zertifizierung;

Ausbeutung;

Begleiten;

Verfügung.

5. Sonderverfahren:

Definition und Herstellung von Zusammenhängen ausgehend von Aufgaben und Zwecken.

Etablierung von Kern-IP-Softwarelebenszyklusprozessen (ISO/IEC 15288)

Prozess (Prozessausführer)	Aktionen	Eingang	Ergebnis
Akquise (Kunde)	- Initiierung - Erstellung von Angebotsvorschlägen - Vertragsvorbereitung - Lieferantenaktivitätskontrolle - IP-Abnahme	- Entscheidung, mit der Arbeit zur Implementierung von IP zu beginnen - Ergebnisse einer Umfrage zu Kundenaktionen - Ergebnisse einer Analyse des IP-Marktes / Ausschreibung - Liefer- / Entwicklungsplan - Umfassender Test von IP	- Machbarkeitsstudie für die Einführung von IS - Leistungsbeschreibung für IS - Liefer-/Entwicklungsvertrag - Abnahmeakte von Arbeitsschritten - Abnahmeakte
Lieferung (IS-Entwickler)	- Anbahnung - Angebotsabgabe - Vertragsvorbereitung - Ausführungsplanung - IP-Versorgung	- Aufgabenstellung für IS - Entscheidung des Managements zur Teilnahme an der Entwicklung - Ergebnisse der Ausschreibung - Aufgabenstellung für IS - Projektmanagementplan - Entwickelte IS und Dokumentation	- Entscheidung über die Teilnahme an der Entwicklung - Kommerzielle Angebote / Angebot - Vertrag für die Lieferung / Entwicklung - Projektmanagementplan - Implementierung / Anpassung - Abnahmeprüfbericht
Entwicklung (IS-Entwickler)	- Vorbereitung - IS-Anforderungsanalyse - IS-Architekturdesign - Entwicklung von Softwareanforderungen - Softwarearchitekturdesign - Detailliertes Softwaredesign - Softwarecodierung und -test - Softwareintegration und Softwarequalifizierungstests - IS-Integration und IS-qualifiziertes Testen	- Aufgabenstellung für IS - Aufgabenstellung für IS, Lebenszyklusmodell - IS-Subsysteme - Anforderungsspezifikationen für Softwarekomponenten - Softwarearchitektur - Detaillierte Softwaredesignmaterialien - Softwareintegrationsplan, Tests - IS-Architektur, Software, Dokumentation für IS, Tests	- Das verwendete Lebenszyklusmodell, Entwicklungsstandards - Der Arbeitsplan - Die Zusammenstellung von Subsystemen, Hardwarekomponenten - Spezifikation von Anforderungen an Softwarekomponenten - Die Zusammenstellung von Softwarekomponenten, Schnittstellen zur Datenbank, der Softwareintegrationsplan - Das Datenbankprojekt, Spezifikationen für Schnittstellen zwischen Softwarekomponenten, Anforderungen an Tests - Modultexte Software, Akte des autonomen Testens - Bewertung der Konformität des Softwarekomplexes mit den Anforderungen der TOR - Bewertung der Konformität von Software, Datenbank, technischer Komplex und eine Reihe von Unterlagen zu den Anforderungen der TOR

Systementwicklungsphasen (ISO/IEC 15288)

CPC: Erstellung von Aufgabenstellungen für das Projekt „Queue“ auf der Website www.mastertz.ru

Software-Lebenszyklusmodelle:

1. Kaskade,

2. Spirale,

3. iterativ.

Kaskadenmodell Lebenszyklus („waterfall model“, englisches Wasserfallmodell) wurde 1970 von Winston Royce vorgeschlagen. Es sieht die sequentielle Durchführung aller Phasen des Projekts in einer streng festgelegten Reihenfolge vor. Der Übergang zur nächsten Stufe bedeutet den vollständigen Abschluss der Arbeiten der vorherigen Stufe.

Die bei der Anforderungserstellung definierten Anforderungen werden im Formblatt streng dokumentiert Bezugsbedingungen und sind für die Dauer des Projekts festgeschrieben.

Jede Stufe gipfelt in der Veröffentlichung eines vollständigen Dokumentationssatzes, der ausreicht, um die Entwicklung von einem anderen Entwicklungsteam fortzusetzen.

Anforderungsentwicklung

Formation

Spiralmodell(engl. spiral model) wurde Mitte der 1980er Jahre von Barry Boehm entwickelt. Es basiert auf dem klassischen PDCA-Zyklus (Plan-Do-Check-Act) von Edward Deming. Bei diesem Modell wird Software in mehreren Iterationen (Spiralturns) durch Prototyping erstellt.

Ein Prototyp ist eine aktive Softwarekomponente, die einzelne Funktionen und externe Schnittstellen implementiert.

Jede Iteration entspricht der Erstellung eines Fragments oder einer Version der Software, sie verdeutlicht die Ziele und Eigenschaften des Projekts, bewertet die Qualität der erzielten Ergebnisse und plant die Arbeit der nächsten Iteration.

Reis. 21. Spiralmodell des Software-Lebenszyklus

Bei jeder Iteration wird Folgendes ausgewertet:

1. Das Risiko, die Bedingungen und Kosten des Projekts zu überschreiten;

2. Die Notwendigkeit, eine weitere Iteration durchzuführen;

3. Grad der Vollständigkeit und Genauigkeit des Verständnisses der Anforderungen an das System;

4. Die Zweckmäßigkeit der Beendigung des Projekts.

Ein Beispiel für die Implementierung des Spiralmodells ist RAD.

Grundprinzipien von RAD:

1. Das Toolkit sollte darauf abzielen, die Entwicklungszeit zu minimieren;

2. Erstellung eines Prototyps zur Klärung der Kundenanforderungen;

3. Entwicklungszyklus: Jede neue Version des Produkts basiert auf der Bewertung des Ergebnisses der Arbeit der vorherigen Version durch den Kunden;

4. Minimierung der Versionsentwicklungszeit durch Übertragen fertiger Module und Hinzufügen von Funktionalität zur neuen Version;

5. Das Entwicklungsteam muss eng zusammenarbeiten, jedes Mitglied muss bereit sein, mehrere Aufgaben zu übernehmen;

6. Das Projektmanagement sollte die Dauer des Entwicklungszyklus minimieren.

Iteratives Modell: Die natürliche Entwicklung der Kaskaden- und Spiralmodelle hat zu ihrer Konvergenz und der Entstehung eines modernen iterativen Ansatzes geführt, der eine rationale Kombination dieser Modelle darstellt.

Reis. 22. Iteratives Modell des Softwarelebenszyklus

Die Entwicklung der CT erweitert ständig die Klassen der zu lösenden Aufgaben im Zusammenhang mit der Verarbeitung von Informationen unterschiedlicher Natur.

Dies sind im Wesentlichen drei Arten von Informationen und dementsprechend drei Klassen von Aufgaben, für die Computer verwendet werden:

1) Rechenaufgaben im Zusammenhang mit der Verarbeitung numerischer Informationen. Dazu gehört beispielsweise das Problem der Lösung eines hochdimensionalen linearen Gleichungssystems. Früher war es das wichtigste, dominierende Einsatzgebiet von Computern.

2) Aufgaben zur Verarbeitung symbolischer Informationen im Zusammenhang mit der Erstellung, Bearbeitung und Transformation von Textdaten. Mit der Lösung solcher Probleme ist beispielsweise die Arbeit einer Sekretärin verbunden.

3) Aufgaben zur Verarbeitung grafischer Informationen, d. h. Diagramme, Zeichnungen, Grafiken, Skizzen usw. Zu solchen Aufgaben gehört beispielsweise die Aufgabe, Zeichnungen neuer Produkte durch einen Designer zu entwickeln.

4) Aufgaben zur Verarbeitung alphanumerischer Informationen - IS. Heutzutage ist es eines der Hauptanwendungsgebiete von Computern geworden und die Aufgaben werden immer komplizierter.

Die Computerlösung von Problemen jeder Klasse hat ihre eigenen Besonderheiten, kann aber in mehrere Phasen unterteilt werden, die für die meisten Probleme typisch sind.

Programmiertechnikuntersucht technologische Prozesse und die Reihenfolge ihres Durchgangs (Stufen) unter Verwendung von Wissen, Methoden und Mitteln.

Technologien werden praktischerweise in zwei Dimensionen charakterisiert – vertikal (stellt Prozesse dar) und horizontal (stellt Stufen dar).

Bild

Ein Prozess ist eine Reihe zusammenhängender Aktionen (technologische Operationen), die einige Eingabedaten in Ausgabedaten umwandeln. Prozesse bestehen aus einer Reihe von Aktionen (technologischen Operationen), und jede Aktion besteht aus einer Reihe von Aufgaben und Methoden zu deren Lösung. Die vertikale Dimension spiegelt die statischen Aspekte der Prozesse wider und arbeitet mit Begriffen wie Arbeitsprozesse, Aktionen, Aufgaben, Leistungsergebnisse, Ausführende.

Eine Phase ist ein Teil der Softwareentwicklungsaktivitäten, der durch einen bestimmten Zeitrahmen begrenzt ist und mit der Veröffentlichung eines bestimmten Produkts endet, das durch die für diese Phase festgelegten Anforderungen bestimmt wird. Manchmal werden Phasen zu größeren Zeitrahmen zusammengefasst, die als Phasen oder Meilensteine ​​bezeichnet werden. Die horizontale Dimension stellt also die Zeit dar, spiegelt die dynamischen Aspekte von Prozessen wider und arbeitet mit Konzepten wie Phasen, Phasen, Stufen, Iterationen und Kontrollpunkten.

Softwareentwicklung folgt einem bestimmten Lebenszyklus.

Lebenszyklus Software ist eine kontinuierliche und geordnete Reihe von Aktivitäten, die im Rahmen jedes Projekts zur Entwicklung und zum Betrieb von Software ausgeführt und verwaltet werden, beginnend mit dem Moment, in dem eine Idee (Konzept) für die Erstellung einer Software auftaucht und eine Entscheidung darüber getroffen wird erstellen müssen, und endet im Moment des vollständigen Entzugs aus der Verwertung aus Gründen:

a) Veralterung;

b) Verlust der Notwendigkeit, die entsprechenden Aufgaben zu lösen.

Technologische Ansätze sind Mechanismen zur Umsetzung des Lebenszyklus.

Der technologische Ansatz wird durch die Besonderheiten der Kombination von Phasen und Prozessen bestimmt, die sich auf verschiedene Softwareklassen und auf die Eigenschaften des Entwicklungsteams konzentrieren.

Der Lebenszyklus definiert die Phasen (Phasen, Stadien), so dass sich das Softwareprodukt von einer Phase zur nächsten bewegt, beginnend mit der Konzeption des Produkts und endend mit der Phase seiner Faltung.

Der Lebenszyklus der Softwareentwicklung kann mit unterschiedlichem Detaillierungsgrad der Stufen dargestellt werden. Die einfachste Darstellung des Lebenszyklus umfasst die Phasen:

Entwurf

Implementierung

Testen und Debuggen

Implementierung, Betrieb und Wartung.

Die einfachste Darstellung des Lebenszyklus des Programms (Ansatz der Kaskadentechnologie für das Lebenszyklusmanagement):

Prozesse

Entwurf

Programmierung

Testen

Begleiten

Analyse Design Implementierung Testen Implementierung Betrieb

und Debugging und Wartung

Tatsächlich läuft in jeder Phase nur ein Prozess. Offensichtlich ist ein solches Schema bei der Entwicklung und Erstellung großer Programme nicht korrekt genug (nicht anwendbar), aber es kann als Grundlage genommen werden.

Alyse-Stadium konzentriert sich auf die Systemanforderungen. Anforderungen werden definiert und spezifiziert (beschrieben). Die Entwicklung und Integration von Funktionsmodellen und Datenmodellen für das System wird durchgeführt. Darüber hinaus werden nichtfunktionale und andere Systemanforderungen festgelegt.

Die Entwurfsphase ist in zwei Hauptunterphasen unterteilt: Architektur- und Detailentwurf. Insbesondere werden das Programmdesign, die Benutzeroberfläche und die Datenstrukturen verfeinert. Designprobleme, die die Verständlichkeit, Wartbarkeit und Skalierbarkeit des Systems beeinträchtigen, werden angesprochen und behoben.

Implementierungsphase beinhaltet das Schreiben eines Programms.

Unterschiede in Hard- und Software sind besonders auf der Bühne sichtbar Ausbeutung. Wenn Konsumgüter die Stadien Markteinführung, Wachstum, Reife und Niedergang durchlaufen, dann gleicht das Leben von Software eher der Geschichte eines unfertigen, aber ständig fertiggestellten und aktualisierten Gebäudes (Flugzeugs) (Teilnehmer).

Der Software-Lebenszyklus wird durch viele, auch internationale Standards geregelt.

Der Zweck der Standardisierung des Lebenszyklus von komplexen PS:

Zusammenfassung der Erfahrungen und Forschungsergebnisse vieler Spezialisten;

Abarbeiten technologische Prozesse und Entwicklungstechniken sowie eine methodische Grundlage für deren Automatisierung.

Zu den Standards gehören:

Regeln zur Beschreibung der Ausgangsinformationen, Methoden und Methoden zur Durchführung von Operationen;

Legen Sie Regeln zur Prozesssteuerung fest;

Anforderungen an die Präsentation der Ergebnisse festlegen;

Regulieren Sie den Inhalt von technologischen und betrieblichen Dokumenten;

Bestimmen Sie die Organisationsstruktur des Entwicklungsteams;

Verteilung und Planung von Aufgaben bereitstellen;

Bieten Sie Kontrolle über den Fortschritt der PS-Erstellung.

In Russland gibt es Standards, die den Lebenszyklus regeln:

Phasen der Softwareentwicklung - GOST 19.102-77

Phasen der Erstellung von AS - GOST 34.601-90;

TK für die Erstellung von AS - GOST 34.602-89;

Testarten AS - GOST 34.603-92;

Allerdings werden die Erstellung, Wartung und Entwicklung von Anwendungssoftware für IP in diesen Standards nicht ausreichend berücksichtigt, und einige ihrer Bestimmungen sind aus Sicht des Aufbaus moderner verteilter Systeme von hochwertigen Anwendungsprogrammen in Steuerungs- und Datenverarbeitungssystemen mit veraltet unterschiedliche Architekturen.

In diesem Zusammenhang ist die internationale Norm ISO / IEC 12207-1999 zu beachten - „ Informationstechnologie– Software-Lebenszyklusprozesse“.

ISO - Internationale Organisation für Normung - Internationale Organisation für Normung, IEC - International Electrotechnical Commission - Internationale Elektrotechnische Kommission.

Es definiert die Struktur des Softwarelebenszyklus und seiner Prozesse.

Diese. Software zu erstellen ist keine so einfache Aufgabe, deshalb gibt es Standards, in denen alles geschrieben steht: was wann und wie zu tun ist.

Die Struktur des Softwarelebenszyklus gem internationaler Standard ISO/IEC 12207-95 basiert auf drei Prozessgruppen:

1) die Hauptprozesse des Software-Lebenszyklus (Beschaffung, Bereitstellung, Entwicklung, Betrieb, Wartung). Wir werden uns auf letzteres konzentrieren.

2) Hilfsprozesse, die die Umsetzung der Hauptprozesse sicherstellen ( Dokumentation, Konfigurationsmanagement, Qualitätssicherung, Verifizierung, Validierung, gemeinsame Überprüfung (Assessment), Audit, Problemlösung).

1. KonfigurationsmanagementDas ein Prozess, der die Hauptprozesse des Software-Lebenszyklus unterstützt, in erster Linie die Entwicklungs- und Wartungsprozesse. Bei der Entwicklung komplexer Softwareprojekte, die aus vielen Komponenten bestehen, die jeweils Varianten oder Versionen haben können, stellt sich das Problem, deren Beziehungen und Funktionen zu berücksichtigen, eine einheitliche (d. h. einzige) Struktur zu schaffen und die Entwicklung des gesamten Systems sicherzustellen. Das Konfigurationsmanagement ermöglicht es Ihnen, Änderungen an verschiedenen Softwarekomponenten in allen Phasen ihres Lebenszyklus zu organisieren, systematisch zu berücksichtigen und zu steuern.

2. Überprüfung ist der Prozess der Feststellung, ob der aktuelle Stand der Software erreicht ist diese Phase, die Anforderungen dieser Stufe.

3. Zertifizierung– Bestätigung durch Prüfung und Vorlage objektiver Nachweise, dass die spezifischen Anforderungen für bestimmte Objekte vollständig umgesetzt werden.

4. Gemeinsame Analyse (Bewertung) – systematische Bestimmung des Übereinstimmungsgrades des Objekts mit den festgelegten Kriterien.

5. Rechnungsprüfung– Überprüfung durch eine zuständige Behörde (Person), um eine unabhängige Bewertung des Grades der Konformität von Softwareprodukten oder -prozessen mit festgelegten Anforderungen zu ermöglichen. Untersuchung ermöglicht es Ihnen, die Übereinstimmung der Entwicklungsparameter mit den ursprünglichen Anforderungen zu bewerten. Die Verifizierung überschneidet sich mit dem Testen, das durchgeführt wird, um die Unterschiede zwischen tatsächlichen und erwarteten Ergebnissen festzustellen und um zu beurteilen, ob die Softwareeigenschaften den ursprünglichen Anforderungen entsprechen. Im Prozess der Projektumsetzung nehmen Fragen der Identifizierung, Beschreibung und Kontrolle der Konfiguration einzelner Komponenten und des Gesamtsystems einen wichtigen Platz ein.

3) organisatorische Prozesse (Projektmanagement, Aufbau der Projektinfrastruktur, Definition, Bewertung und Verbesserung des Lebenszyklus selbst, Schulung).

Projektmanagement verbunden mit Fragen der Planung und Organisation der Arbeit, der Bildung von Entwicklerteams und der Überwachung des Timings und der Qualität der geleisteten Arbeit. Die technische und organisatorische Begleitung des Projektes umfasst die Auswahl von Methoden und Werkzeugen zur Durchführung des Projektes, die Definition von Methoden zur Beschreibung der Zwischenstände der Entwicklung, die Entwicklung von Methoden und Werkzeugen zum Testen der erstellten Software, Personalschulungen etc . Die Projektqualitätssicherung bezieht sich auf die Probleme der Verifikation, Verifikation und des Testens von Softwarekomponenten.

Wir betrachten den Software-Lebenszyklus aus der Sicht des Entwicklers.

Der Entwicklungsprozess gemäß der Norm sieht die vom Entwickler durchgeführten Handlungen und Aufgaben vor und umfasst die Erstellung von Software und ihren Komponenten gemäß den festgelegten Anforderungen, einschließlich der Erstellung von Design- und Betriebsdokumentationen sowie der Erstellung von Materialien, die zur Überprüfung der Funktionsfähigkeit und Konformität der Qualität von Softwareprodukten erforderlich sind, Materialien, die für die Schulung des Personals usw. benötigt werden.

Gemäß der Norm umfasst der IP-Softwarelebenszyklus die folgenden Aktionen:

1) die Entstehung und das Studium der Idee (Konzept);

2) Vorbereitungsphase - Auswahl eines Lebenszyklusmodells, Standards, Methoden und Entwicklungstools sowie Erstellung eines Arbeitsplans.

3) Analyse der Anforderungen an Informationssysteme - definieren

Funktionalität, Benutzeranforderungen, Anforderungen an Zuverlässigkeit und Sicherheit, Anforderungen an externe Schnittstellen usw.

4) Design von Informationssystemarchitekturen - Bestimmung der Zusammensetzung notwendige Ausrüstung, Software und Vorgänge, die von Servicepersonal durchgeführt werden.

5) Software-Anforderungsanalyse- Definition der Funktionalität, einschließlich Leistungsmerkmale, Betriebsumgebung von Komponenten, externe Schnittstellen, Zuverlässigkeits- und Sicherheitsspezifikationen, ergonomische Anforderungen, Anforderungen an die Datennutzung, Installation, Abnahme, Benutzerdokumentation, Betrieb und Wartung.

6) Design von Softwarearchitekturen - Definieren der Struktur der Software, Dokumentieren der Schnittstellen ihrer Komponenten, Erstellen einer vorläufigen Version der Benutzerdokumentation sowie Testanforderungen und eines Integrationsplans.

7) detailliertes Softwaredesign - detailliert

Beschreibung von Softwarekomponenten und Schnittstellen zwischen ihnen, Aktualisierung der Benutzerdokumentation, Entwicklung und Dokumentation von Testanforderungen und eines Testplans, Softwarekomponenten, Aktualisierung des Komponentenintegrationsplans.

8) Software-Codierung -– Entwicklung und Dokumentation

jede Softwarekomponente;

9)Softwaretest – Entwicklung einer Reihe von Testverfahren und Daten für deren Test, Test von Komponenten, Aktualisierung der Benutzerdokumentation, Aktualisierung des Softwareintegrationsplans;

10) Softwareintegration–Zusammenstellung von Softwarekomponenten gem

Integrationsplan und Testen der Software auf Einhaltung der Qualifizierungsanforderungen, bei denen es sich um eine Reihe von Kriterien oder Bedingungen handelt, die erfüllt sein müssen, um ein Softwareprodukt als seinen Spezifikationen entsprechend und unter bestimmten Betriebsbedingungen einsatzbereit zu qualifizieren;

11) Software-Qualifikationstests – Softwaretests in

die Anwesenheit des Kunden, um seine Einhaltung nachzuweisen

Anforderungen und Einsatzbereitschaft; gleichzeitig wird auch die Bereitschaft und Vollständigkeit der Fach- und Anwenderdokumentation geprüft;

12) System Integration – Montage aller Komponenten des Informationssystems, einschließlich Software und Hardware;

13) IP-Qualifikationsprüfung – Systemtest für

Einhaltung der Anforderungen dafür und Überprüfung der Gestaltung und Vollständigkeit der Dokumentation;

14) Software Installation – Installation von Software auf den Geräten des Kunden und Überprüfung ihrer Leistung;;

15) Softwareakzeptanz – Auswertung der Ergebnisse eines qualifizierten

Software- und Informationssystemtests im Allgemeinen und

Dokumentation der Evaluierungsergebnisse gemeinsam mit dem Kunden, Zertifizierung und abschließende Übergabe der Software an den Kunden.

16) Verwaltung und Entwicklung der Dokumentation;

17) Betrieb

18) Eskorte - der Prozess der Erstellung und Implementierung neuer Versionen

Softwareprodukt.;

19) Abschluss der Operation.

Diese Aktionen können gruppiert werden, wobei die folgenden Hauptphasen der Softwareentwicklung bedingt hervorgehoben werden:

Aufgabenstellung (TOR) (gemäß GOST 19.102-77 Stufe "Terms of Reference")

Wir sollten mit der Definition beginnenSoftware-Lebenszyklus(Software-Lebenszyklusmodell) ist ein Zeitraum, der von dem Moment an beginnt, in dem eine Entscheidung getroffen wird, ein Softwareprodukt zu erstellen, und in dem Moment endet, in dem es vollständig aus dem Dienst genommen wird. Dieser Zyklus ist der Prozess des Erstellens und Entwickelns von Software.

Software-Lebenszyklusmodelle

Der Lebenszyklus kann in Form von Modellen dargestellt werden. Die derzeit gängigsten sind:Kaskadierung, inkrementell (Stufenmodell mit Zwischensteuerung ) und Spiral-Lebenszyklusmodelle.

Kaskadenmodell

Kaskadenmodell(engl. Wasserfall-Modell) ist ein Modell des Softwareentwicklungsprozesses, dessen Lebenszyklus wie ein Fluss aussieht, der nacheinander die Phasen Anforderungsanalyse, Design durchläuft. Implementierung, Test, Integration und Support.

Der Entwicklungsprozess wird durch eine geordnete Abfolge unabhängiger Schritte implementiert. Das Modell sieht vor, dass jeder nachfolgende Schritt nach Abschluss des vorherigen Schritts beginnt. Auf allen Stufen des Modells werden unterstützende und organisatorische Prozesse und Arbeiten durchgeführt, einschließlich Projektmanagement, Bewertungs- und Qualitätsmanagement, Verifizierung und Zertifizierung, Konfigurationsmanagement und Dokumentationsentwicklung. Durch den Abschluss von Schritten entstehen Zwischenprodukte, die in nachfolgenden Schritten nicht mehr verändert werden können.

Der Lebenszyklus wird traditionell in die folgenden Hauptbereiche unterteiltStufen:

1. Anforderungsanalyse,
2. Entwurf,
3. Codierung (Programmierung),
4. Testen und Debuggen,
5. Betrieb und Instandhaltung.

Vorteile des Modells:

• Stabilität der Anforderungen während des gesamten Entwicklungslebenszyklus;
• In jeder Phase wird eine vollständige Projektdokumentation erstellt, die die Kriterien für Vollständigkeit und Konsistenz erfüllt.
• die Sicherheit und Verständlichkeit der Schritte des Modells und die Einfachheit seiner Anwendung;
• Die in logischer Abfolge ausgeführten Arbeitsschritte ermöglichen es Ihnen, den Zeitpunkt der Fertigstellung aller Arbeiten und die entsprechenden Ressourcen (Geld, Material und Personal) zu planen.

Nachteile des Modells:

• die Komplexität der klaren Formulierung von Anforderungen und die Unmöglichkeit ihrer dynamischen Veränderung während des gesamten Lebenszyklus;
• geringe Flexibilität im Projektmanagement;
• die Abfolge der linearen Struktur des Entwicklungsprozesses, wodurch die Rückkehr zu vorherigen Schritten zur Lösung aufkommender Probleme zu einer Erhöhung der Kosten und einer Unterbrechung des Arbeitsplans führt;
• Ungeeignetheit des Zwischenprodukts für den Gebrauch;
• Unmöglichkeit der flexiblen Modellierung einzigartiger Systeme;
• spätes Erkennen von baubedingten Problemen durch gleichzeitige Integration aller Ergebnisse am Ende der Entwicklung;
• unzureichende Beteiligung der Benutzer an der Erstellung des Systems - ganz am Anfang (während der Entwicklung der Anforderungen) und am Ende (während der Abnahmetests);
• Anwender können erst am Ende des gesamten Entwicklungsprozesses von der Qualität des entwickelten Produkts überzeugt werden. Sie haben keine Möglichkeit, die Qualität zu beurteilen, weil sie das fertige Produkt der Entwicklung nicht sehen können;
• der Benutzer hat keine Möglichkeit, sich allmählich an das System zu gewöhnen. Der Lernprozess findet am Ende des Lebenszyklus statt, wenn die Software bereits in Betrieb genommen wurde;
• Jede Phase ist eine Voraussetzung für die Ausführung nachfolgender Aktionen, was eine solche Methode zu einer riskanten Wahl für Systeme macht, die keine Analoga haben, weil. es eignet sich nicht für eine flexible Modellierung.

Aufgrund der Komplexität der Entwicklung von PS ist es schwierig, das Wasserfall-Lebenszyklusmodell zu implementieren, ohne zu vorherigen Schritten zurückzukehren und ihre Ergebnisse zu ändern, um auftretende Probleme zu beseitigen.

Geltungsbereich des Kaskadenmodells

Die Begrenzung des Anwendungsbereichs des Kaskadenmodells wird durch seine Mängel bestimmt. Seine Verwendung ist in den folgenden Fällen am effektivsten:

1. bei der Entwicklung von Projekten mit klaren, unveränderlichenLebenszyklus Anforderungen, die durch Implementierung und technische Methoden verständlich sind;
2. bei der Entwicklung eines Projekts, das sich auf den Bau eines Systems oder Produkts des gleichen Typs konzentriert, wie es zuvor von Entwicklern entwickelt wurde;
3. bei der Entwicklung eines Projekts im Zusammenhang mit der Erstellung und Veröffentlichung einer neuen Version eines bestehenden Produkts oder Systems;
4. bei der Entwicklung eines Projekts im Zusammenhang mit der Übertragung eines bestehenden Produkts oder Systems auf eine neue Plattform;
5. bei der Durchführung großer Projekte mit mehreren großen Entwicklungsteams.

inkrementelles Modell

(Stufenmodell mit Zwischensteuerung)

inkrementelles Modell(engl. Zuwachs- Erhöhung, Inkrement) impliziert die Entwicklung von Software mit einer linearen Abfolge von Stufen, jedoch in mehreren Inkrementen (Versionen), d.h. mit geplanten Produktverbesserungen, solange der Software Development Life Cycle zu Ende geht.

Die Softwareentwicklung erfolgt in Iterationen mit Rückkopplungsschleifen zwischen den Stufen. Stufenübergreifende Anpassungen ermöglichen es, die tatsächliche gegenseitige Beeinflussung der Entwicklungsergebnisse in verschiedenen Stufen zu berücksichtigen, die Lebensdauer der einzelnen Stufen wird über den gesamten Entwicklungszeitraum verlängert.

Zu Beginn der Projektarbeit werden alle grundlegenden Anforderungen an das System ermittelt, unterteilt in mehr und weniger wichtige. Danach erfolgt die Entwicklung des Systems inkrementell, sodass der Entwickler die bei der Entwicklung der Software gewonnenen Daten nutzen kann. Jedes Inkrement sollte dem System bestimmte Funktionalität hinzufügen. In diesem Fall beginnt die Freigabe mit den Komponenten mit der höchsten Priorität. Sobald die Teile des Systems definiert sind, nehmen Sie den ersten Teil und beginnen Sie, ihn mit dem am besten geeigneten Prozess zu detaillieren. Gleichzeitig ist es möglich, die Anforderungen für andere Teile zu verfeinern, die im aktuellen Anforderungskatalog dieser Arbeit eingefroren wurden. Bei Bedarf können Sie später zu diesem Teil zurückkehren. Wenn das Teil fertig ist, wird es an den Kunden geliefert, der es für seine Arbeit verwenden kann. Dadurch kann der Kunde die Anforderungen für die folgenden Komponenten klären. Dann entwickeln sie den nächsten Teil des Systems. Die wichtigsten Schritte in diesem Prozess bestehen einfach darin, eine Teilmenge von Softwareanforderungen zu implementieren und das Modell über eine Reihe aufeinanderfolgender Releases zu verfeinern, bis die gesamte Software implementiert ist.

Der Lebenszyklus dieses Modells ist typisch für die Entwicklung komplexer und komplexer Systeme, für die es eine klare Vorstellung (sowohl seitens des Kunden als auch des Entwicklers) gibt, wie das Endergebnis aussehen soll. Die Versionsentwicklung wird aus verschiedenen Gründen durchgeführt:

• die Unfähigkeit des Kunden, das gesamte teure Projekt sofort zu finanzieren;
• dem Entwickler fehlen die notwendigen Ressourcen, um ein komplexes Projekt in kurzer Zeit umzusetzen;
• Anforderungen für die schrittweise Implementierung und Entwicklung des Produkts durch Endbenutzer. Die Einführung des gesamten Systems auf einmal kann bei seinen Benutzern Ablehnung hervorrufen und den Übergangsprozess zu neuen Technologien nur „verlangsamen“. Bildlich gesprochen können sie „ein großes Stück einfach nicht verdauen, also muss es zerkleinert und in Teilen gegeben werden“.

Vorteile und Einschränkungendieses Modells (Strategie) sind die gleichen wie die der Kaskade (klassisches Lebenszyklusmodell). Aber anders als bei der klassischen Strategie sieht der Kunde die Ergebnisse früher. Basierend auf den Ergebnissen der Entwicklung und Implementierung der ersten Version kann er die Anforderungen an die Entwicklung geringfügig ändern, auf diese verzichten oder die Entwicklung eines fortschrittlicheren Produkts mit Abschluss eines neuen Vertrages anbieten.

Vorteile:

• Kosten, die durch sich ändernde Benutzeranforderungen entstehen, werden reduziert, Reanalysen und Dokumentationserhebungen werden im Vergleich zum Wasserfallmodell erheblich reduziert;
• Es ist einfacher, Feedback vom Kunden über die geleistete Arbeit zu erhalten - Kunden können ihre Kommentare zu fertigen Teilen äußern und sehen, was bereits erledigt wurde. Da die ersten Teile des Systems sind der Prototyp des Gesamtsystems.
• der Kunde hat die Möglichkeit, die Software schnell zu erwerben und zu beherrschen – Kunden können früher echte Vorteile aus dem System ziehen, als dies mit dem Wasserfallmodell möglich wäre.

Nachteile des Modells:

• Manager müssen den Fortschritt des Prozesses ständig messen. bei schneller Entwicklung lohnt es sich nicht, für jede minimale Versionsänderung Dokumente zu erstellen;
• die Struktur des Systems neigt dazu, sich zu verschlechtern, wenn neue Komponenten hinzugefügt werden - ständige Änderungen stören die Struktur des Systems. Um dies zu vermeiden, sind zusätzliche Zeit und Geld für das Refactoring erforderlich. Eine schlechte Struktur macht es schwierig und kostspielig, Software später zu ändern. Und der unterbrochene Software Life Cycle führt zu noch größeren Verlusten.

Das Schema erlaubt es nicht, sich abzeichnende Änderungen und Klarstellungen von Softwareanforderungen zeitnah zu berücksichtigen. Die Abstimmung der Entwicklungsergebnisse mit den Benutzern erfolgt nur an den vorgesehenen Stellen nach Abschluss der jeweiligen Arbeitsphase und Allgemeine Anforderungen an die Software sind in Form einer technischen Aufgabe für die gesamte Zeit ihrer Erstellung fixiert. So erhalten Nutzer oft Software, die nicht ihren wirklichen Bedürfnissen entspricht.

Spiralmodell

Spiralmodell:Lebenszyklus - bei jeder Umdrehung der Spirale wird die nächste Version des Produkts erstellt, die Anforderungen des Projekts werden spezifiziert, seine Qualität wird bestimmt und die Arbeit der nächsten Umdrehung wird geplant. Besonderes Augenmerk wird auf die Anfangsphasen der Entwicklung gelegt - Analyse und Design, wo die Machbarkeit sicher ist technische Lösungen durch Prototyping getestet und begründet.

Dieses Modell ist ein Softwareentwicklungsprozess, der sowohl Design als auch gestuftes Prototyping kombiniert, um die Vorteile von Bottom-up- und Top-down-Konzepten zu kombinieren, wobei der Schwerpunkt auf den Anfangsphasen des Lebenszyklus liegt: Analyse und Design.Unterscheidungsmerkmal Dieses Modell ist ein besonderes Augenmerk auf die Risiken, die die Organisation des Lebenszyklus betreffen.

In den Phasen Analyse und Design wird die Machbarkeit technischer Lösungen und der Grad der Befriedigung der Kundenbedürfnisse durch die Erstellung von Prototypen überprüft. Jede Drehung der Spirale entspricht der Schaffung eines funktionsfähigen Fragments oder einer Version des Systems. Auf diese Weise können Sie die Anforderungen, Ziele und Eigenschaften des Projekts klären, die Qualität der Entwicklung bestimmen und die Arbeit der nächsten Windung der Spirale planen. So werden die Details des Projekts vertieft und konsequent konkretisiert und im Ergebnis eine sinnvolle Option ausgewählt, die den tatsächlichen Anforderungen des Kunden entspricht und zur Umsetzung gebracht.

Lebenszyklus auf jeder Umdrehung der Spirale - verschiedene Modelle des Softwareentwicklungsprozesses können angewendet werden. Das Endergebnis ist ein fertiges Produkt. Das Modell kombiniert die Fähigkeiten eines Prototyping-Modells undWasserfall-Modell. Entwicklung durch Iterationen spiegelt den objektiv existierenden Spiralkreislauf der Systemerstellung wider. Der unvollständige Abschluss der Arbeit in jeder Phase ermöglicht es Ihnen, mit der nächsten Phase fortzufahren, ohne auf den vollständigen Abschluss der Arbeit an der aktuellen zu warten. Die Hauptaufgabe- Benutzern des Systems schnellstmöglich ein funktionsfähiges Produkt aufzuzeigen und damit den Prozess der Klärung und Ergänzung von Anforderungen zu aktivieren.

Vorteile des Modells:

• ermöglicht es Ihnen, Benutzern des Systems schnell ein funktionsfähiges Produkt zu zeigen und dadurch den Prozess der Klärung und Ergänzung von Anforderungen zu aktivieren;
• ermöglicht Änderungen der Anforderungen während der Softwareentwicklung, was typisch für die meisten Entwicklungen ist, einschließlich Standardentwicklungen;
• das Modell ermöglicht eine flexible Gestaltung, da es die Vorteile des Kaskadenmodells verkörpert und gleichzeitig Iterationen über alle Phasen desselben Modells erlaubt sind;
• ermöglicht Ihnen ein zuverlässigeres und stabileres System. Während sich die Software weiterentwickelt, werden bei jeder Iteration Fehler und Schwachstellen gefunden und behoben;
• Dieses Modell ermöglicht es Benutzern, sich aktiv an der Planung, Risikoanalyse, Entwicklung sowie an der Durchführung von Bewertungsaktivitäten zu beteiligen;
• Kundenrisiko reduzieren. Der Kunde kann, mit einem Minimum für sich selbst finanzielle Verluste die Entwicklung eines aussichtslosen Projekts abschließen;
• Rückmeldungen von Benutzern an Entwickler werden häufig und früh im Modell durchgeführt, wodurch sichergestellt wird, dass das gewünschte Produkt von hoher Qualität ist.

Nachteile des Modells:

• Wenn das Projekt risikoarm oder klein ist, kann das Modell teuer sein. Risikobewertung nach jeder Spirale ist teuer;
• Der Lebenszyklus des Modells hat eine komplizierte Struktur, sodass seine Anwendung durch Entwickler, Manager und Kunden schwierig sein kann;
• die Spirale kann unendlich weitergehen, da die Reaktion jedes Kunden auf die erstellte Version einen neuen Zyklus erzeugen kann, der den Abschluss des Projekts verzögert;
• eine große Anzahl von Zwischenzyklen kann dazu führen, dass zusätzliche Unterlagen verarbeitet werden müssen;
• die Verwendung des Modells kann kostspielig und sogar unbezahlbar sein, weil Zeit. die Ausgaben für Planung, Neuausrichtung, Durchführung von Risikoanalysen und Prototypen können übermäßig sein;
• Es kann schwierig sein, Ziele und Meilensteine ​​zu definieren, die die Bereitschaft anzeigen, den Entwicklungsprozess beim nächsten Mal fortzusetzen

Das Hauptproblem des Spiralzyklus besteht darin, den Zeitpunkt des Übergangs zur nächsten Stufe zu bestimmen. Um es zu lösen, werden Zeitlimits für jede der Stufen eingeführt.Lebenszyklus und der Übergang planmäßig verläuft, auch wenn noch nicht alle geplanten Arbeiten abgeschlossen sind.Planungerstellt auf der Grundlage statistischer Daten aus früheren Projekten und persönliche Erfahrung Entwickler.

Anwendungsbereich des Spiralmodells

Die Verwendung des Spiralmodells ist in folgenden Fällen ratsam:

• bei der Entwicklung von Projekten mit neuen Technologien;
• beim Entwickeln Neue Serien Produkte oder Systeme;
• bei der Entwicklung von Projekten mit erwarteten wesentlichen Änderungen oder Ergänzungen der Anforderungen;
• für die Umsetzung langfristiger Projekte;
• bei der Entwicklung von Projekten, die den Nachweis der Qualität und Versionen eines Systems oder Produkts über einen kurzen Zeitraum erfordern;
• bei der Entwicklung von Projekten. für die es notwendig ist, die mit der Bewertung und Beseitigung von Risiken verbundenen Kosten zu berechnen.