Was ist im Software-Lebenszyklus enthalten? Software-Lebenszyklus

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, darunter 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 Reihenfolge 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 Phasen. Stufenübergreifende Anpassungen ermöglichen es, die tatsächliche gegenseitige Beeinflussung von Entwicklungsergebnissen in verschiedenen Stufen zu berücksichtigen, die Lebensdauer jeder der 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. Wenn die Teile des Systems definiert sind, nehmen Sie den ersten Teil und beginnen Sie mit der Detaillierung, indem Sie den dafür am besten geeigneten Prozess verwenden. 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 sind die einfache Implementierung einer Teilmenge von Softwareanforderungen und die Verfeinerung des Modells über eine Reihe aufeinanderfolgender Releases, bis die Software vollständig 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 mangelnde Fähigkeit des Kunden, das gesamte teure Projekt sofort zu finanzieren;
• das Fehlen der notwendigen Ressourcen für den Entwickler, 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 Anwendern erfolgt nur an den vorgesehenen Stellen nach Abschluss der jeweiligen Arbeitsschritte und die allgemeinen Anforderungen an die Software werden in Form einer fachlichen Aufgabe für die gesamte Zeit ihrer Entstehung 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 bestimmter technischer Lösungen getestet und durch die Erstellung von Prototypen begründet wird.

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 besteht darin, den Nutzern des Systems schnellstmöglich ein lauffähiges Produkt aufzuzeigen und damit den Prozess der Klärung und Ergänzung von Anforderungen anzustoßen.

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 die Entwicklung eines aussichtslosen Projekts mit minimalen finanziellen Verlusten 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.Planungbasiert auf statistischen Daten aus früheren Projekten und persönlichen Erfahrungen von Entwicklern.

Anwendungsbereich des Spiralmodells

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

• bei der Entwicklung von Projekten mit neuen Technologien;
• bei der Entwicklung einer neuen Serie von Produkten oder Systemen;
• 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.

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 (Software) zunächst in den 70er Jahren des letzten Jahrhunderts durch die GOST ESPD-Standards (Unified System for Program Documentation - GOST 19.XXX Serien), die sich auf die Klasse relativ einfacher Programme mit kleinem Volumen 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.

Gemäß der Norm ISO/IEC 12207 werden alle Software-Lebenszyklusprozesse in drei Gruppen eingeteilt (Abb. 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 Angebote 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, der die Organisationsstruktur des Projekts, die Abgrenzung der Verantwortlichkeiten, die technischen Anforderungen an die Entwicklungsumgebung und die Ressourcen, die Verwaltung von Unterauftragnehmern usw. enthält.

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 Vorbereitung 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.

Anmerkung.

Einführung.

1. Softwarelebenszyklus

Einführung.

Schritte des Riley-Programmierungsprozesses

Einführung.

1.1.1. Formulierung des Problems.

1.1.2. Lösungsdesign.

1.1.3. Algorithmus-Codierung.

1.1.4. Programmunterstützung.

1.1.5. Softwaredokumentation.

Fazit zu Ziffer 1.1

1.2. Definition von ZhTsPO nach Lehman.

Einführung.

1.2.1 Systemdefinition.

1.2.2. Implementierung.

1.2.3. Service.

Fazit zu Punkt 1.2.

1.3. Phasen und Arbeiten des Lebenszyklusprogramms nach Böhm

1.3.1. Kaskadenmodell.

1.3.2. Ökonomische Begründung des Kaskadenmodells.

1.3.3. Verbesserung des Kaskadenmodells.

1.3.4. Definition von Lebenszyklusphasen.

1.3.5. Grundlegende Arbeit am Projekt.

Literatur.

Einführung

Die industrielle Anwendung von Computern und die wachsende Nachfrage nach Programmen stellen vordringliche Aufgaben für eine deutliche Steigerung der Produktivität der Softwareentwicklung, die Entwicklung industrieller Methoden zur Planung und Gestaltung von Programmen, die Übertragung von organisatorischen, technischen, technischen, wirtschaftlichen und sozialpsychologischen Methoden, Mustern und Methoden aus dem Bereich der materiellen Produktion in den Bereich der Computer. Ein komplexer Ansatz Die Prozesse der Entwicklung, des Betriebs und der Wartung von Software stellen eine Reihe dringender Probleme dar, deren Lösung die "Engpässe" bei der Gestaltung von Programmen beseitigen, die Fertigstellungszeit verkürzen, die Auswahl und Anpassung bestehender Programme verbessern und vielleicht das Schicksal von Systemen mit eingebetteten Computern bestimmen.

In der Praxis der Entwicklung großer Softwareprojekte gibt es oft keine einheitlicher Ansatz auf die Bewertung von Arbeitskosten, Arbeitsbedingungen und Materialkosten, was die Produktivitätssteigerung der Softwareentwicklung und letztendlich das effektive Management des Softwarelebenszyklus behindert. Da ein Programm jeder Art zu einem Produkt wird (mit Ausnahme von Bildungsprogrammen oder Mock-up-Programmen), sollte die Herangehensweise an seine Produktion in vielerlei Hinsicht der Herangehensweise an die Produktion industrieller Produkte ähneln, und Fragen des Softwaredesigns werden äußerst wichtig . Diese Idee liegt B.U. Boehm "Engineering Software Design", die wir beim Verfassen dieser Hausarbeit verwendet haben. In diesem Buch bezieht sich Softwaredesign auf den Prozess der Erstellung eines Designs für ein Softwareprodukt.

1 Softwarelebenszyklus

EINLEITUNG

LCPE ist ein kontinuierlicher Prozess, der mit der Entscheidung über die Notwendigkeit der Softwareerstellung beginnt und mit der vollständigen Außerbetriebnahme endet.

Es gibt mehrere Ansätze, um die Phasen und Aktivitäten des Software-Lebenszyklus (SLLC) zu definieren, Prozessschritte zu programmieren, Wasserfall- und Spiralmodelle. Aber sie alle enthalten gemeinsame grundlegende Komponenten: Problemstellung, Lösungsdesign, Implementierung, Wartung.

Am bekanntesten und vollständigsten ist vielleicht die Struktur des Lebenszyklus nach Böhm, die acht Phasen umfasst. Sie wird später ausführlicher vorgestellt.

Eine der möglichen Optionen kann die Beschreibung der oberen Ebene nach Lehman sein, die drei Hauptphasen umfasst und im allgemeinsten Fall die Beschreibung des Lebenszyklusprogramms darstellt.

Und zur Abwechslung hier die Schritte des Programmierprozesses, die von D. Riley in dem Buch „Using the Modula-2 Language“ vorgestellt werden. Diese Idee ist meiner Meinung nach sehr einfach und vertraut, und wir werden damit beginnen.

1.1 Schritte des Riley-Programmierungsprozesses

Einführung

Der Programmierprozess umfasst vier Schritte (Abb. 1):

Problemstellung, d.h. eine angemessene Vorstellung davon bekommen, welche Aufgabe das Programm erfüllen soll;

Entwerfen einer Lösung für ein bereits gestelltes Problem (im Allgemeinen ist eine solche Lösung weniger formal als das endgültige Programm);

Programmcodierung, d.h. Übersetzung der entworfenen Lösung in ein Programm, das auf einer Maschine ausgeführt werden kann;

Programmunterstützung, d.h. ein laufender Prozess zur Behebung von Fehlern im Programm und zum Hinzufügen neuer Funktionen.

Reis. 1. Vier Programmierschritte.

Die Programmierung beginnt ab dem Zeitpunkt, an dem Benutzer, d.h. Jemand, der ein Programm braucht, um ein Problem zu lösen, stellt ein Problem Systemanalytiker. Der Benutzer und der Systemanalytiker definieren gemeinsam die Problemstellung. Letztere wird dann übertragen Algorithmist wer für das Design der Lösung verantwortlich ist. Eine Lösung (oder ein Algorithmus) ist eine Abfolge von Operationen, deren Ausführung zur Lösung eines Problems führt. Da der Algorithmus oft nicht für die Ausführung auf einer Maschine geeignet ist, sollte er in ein Maschinenprogramm übersetzt werden. Diese Operation wird vom Codierer durchgeführt. Für spätere Änderungen am Programm ist der Betreuer verantwortlich. Programmierer. Und der Systemanalytiker und der Algorithmus und der Programmierer und der begleitende Programmierer – sie alle sind Programmierer.

Bei einem großen Softwareprojekt kann die Anzahl der Benutzer, Systemanalysten und Algorithmen erheblich sein. Darüber hinaus kann es aufgrund unvorhergesehener Umstände erforderlich sein, zu vorherigen Schritten zurückzukehren. All dies ist ein zusätzliches Argument für sorgfältiges Softwaredesign: Die Ergebnisse jedes Schrittes sollten vollständig, genau und nachvollziehbar sein.

1.1.1 Beschreibung des Problems

Einer der wichtigsten Schritte beim Programmieren ist das Setzen eines Problems. Es fungiert als Vertrag zwischen dem Benutzer und dem/den Programmierer(n). Wie ein rechtlich schlecht ausgearbeiteter Vertrag ist ein schlechtes Leitbild nutzlos. Bei einer guten Problemstellung stellen sowohl der Anwender als auch der Programmierer die zu erledigende Aufgabe klar und eindeutig dar, d.h. dabei werden sowohl die Interessen des Benutzers als auch die des Programmierers berücksichtigt. Der Benutzer kann planen, die noch nicht erstellte Software zu verwenden, basierend auf dem Wissen, dass dies möglich ist. Eine gute Formulierung des Problems dient als Grundlage für die Bildung seiner Lösung.

Formulierung des Problems (Programmspezifikation); bedeutet im Wesentlichen eine genaue, vollständige und verständliche Beschreibung dessen, was passiert, wenn ein bestimmtes Programm ausgeführt wird. Der Benutzer betrachtet den Computer normalerweise als Blackbox: Es ist ihm egal, wie der Computer funktioniert, aber es ist wichtig, dass der Computer das kann, was den Benutzer interessiert. Im Mittelpunkt steht die Interaktion zwischen Mensch und Maschine.

Merkmale einer guten Problemstellung:

Genauigkeit, d.h. Ausschluss jeglicher Zweideutigkeit. Es sollte keine Frage geben, was die Ausgabe des Programms für eine gegebene Eingabe sein wird.

Vollständigkeit, d.h. Berücksichtigen aller Optionen für eine gegebene Eingabe, einschließlich fehlerhafter oder unerwarteter Eingaben, und Bestimmen der geeigneten Ausgabe.

Klarheit, d.h. sie sollte sowohl für den Benutzer als auch für den Systemanalytiker verständlich sein, da die Problemstellung der einzige Vertrag zwischen ihnen ist.

Oft stehen die Anforderungen an Genauigkeit, Vollständigkeit und Klarheit im Widerspruch. Viele juristische Dokumente sind daher schwer verständlich, weil sie in einer formalen Sprache verfasst sind, die es Ihnen erlaubt, bestimmte Bestimmungen mit äußerster Präzision zu formulieren und selbst die unbedeutendsten Abweichungen auszuschließen. Beispielsweise sind einige Fragen auf Prüfungsarbeiten manchmal so präzise formuliert, dass der Student mehr Zeit damit verbringt, die Frage zu verstehen, als sie zu beantworten. Darüber hinaus kann es vorkommen, dass der Schüler aufgrund der vielen Details die Hauptbedeutung der Frage überhaupt nicht erfasst. Die beste Problemstellung ist diejenige, die ein Gleichgewicht zwischen allen drei Anforderungen erreicht.

Die Standardform der Problemstellung.

Betrachten Sie die folgende Formulierung des Problems: "Geben Sie drei Zahlen ein und geben Sie die Zahlen der Reihe nach aus."

Eine solche Erklärung genügt den oben genannten Anforderungen nicht: Sie ist weder präzise, ​​noch vollständig, noch verständlich. Sollen die Nummern tatsächlich einzeln pro Zeile oder alle Nummern in einer Zeile eingegeben werden? Bedeutet der Ausdruck „in Reihenfolge“ eine Reihenfolge vom größten zum kleinsten, vom kleinsten zum größten oder dieselbe Reihenfolge, in der sie eingegeben wurden?

Es liegt auf der Hand, dass eine solche Aussage viele Fragen nicht beantwortet. Wenn wir die Antworten auf alle Fragen berücksichtigen, wird die Problemstellung wortreich und schwer verständlich. Daher schlägt D. Riley vor, das Standardformular für die Problemstellung zu verwenden, das maximale Genauigkeit, Vollständigkeit und Klarheit gewährleistet und Folgendes beinhaltet:

Aufgabenname (schematische Definition);

allgemeine Beschreibung (kurze Beschreibung der Aufgabe);

Fehler (ungewöhnliche Eingabemöglichkeiten werden explizit aufgelistet, um Benutzern und Programmierern zu zeigen, welche Maßnahmen die Maschine in solchen Situationen ergreifen wird);

Beispiel (ein gutes Beispiel kann den Kern des Problems vermitteln und verschiedene Fälle veranschaulichen).

Beispiel. Beschreibung des Problems in der Standardform.

TITEL

Sortiere drei ganze Zahlen.

BEZEICHNUNG

Eingabe und Ausgabe von drei ganzen Zahlen, sortiert von der kleinsten zur größten.

Es werden drei ganze Zahlen eingegeben, eine Zahl pro Zeile. In diesem Fall ist eine Ganzzahl eine oder mehrere aufeinanderfolgende Dezimalziffern, denen ein Pluszeichen „+“ oder ein Minuszeichen „-“ vorangestellt sein kann.

Die drei eingegebenen Ganzzahlen werden ausgegeben, wobei alle drei in derselben Zeile angezeigt werden. Benachbarte Zahlen werden durch ein Leerzeichen getrennt. Zahlen werden vom kleinsten zum größten, von links nach rechts angezeigt.

1) Wenn weniger als drei Zahlen eingegeben werden, wartet das Programm auf weitere Eingaben.

2) Andere Eingabezeilen als die ersten drei werden ignoriert.

3) Wenn eine der ersten drei Zeilen mehr als eine ganze Zahl enthält, wird das Programm beendet und eine Nachricht ausgegeben.

Anmerkung.

Einführung.

1. Softwarelebenszyklus

Einführung.

Schritte des Riley-Programmierungsprozesses

Einführung.

1.1.1. Formulierung des Problems.

1.1.2. Lösungsdesign.

1.1.3. Algorithmus-Codierung.

1.1.4. Programmunterstützung.

1.1.5. Softwaredokumentation.

Fazit zu Ziffer 1.1

1.2. Definition von ZhTsPO nach Lehman.

Einführung.

1.2.1 Systemdefinition.

1.2.2. Implementierung.

1.2.3. Service.

Fazit zu Punkt 1.2.

1.3. Phasen und Arbeiten des Lebenszyklusprogramms nach Böhm

1.3.1. Kaskadenmodell.

1.3.2. Ökonomische Begründung des Kaskadenmodells.

1.3.3. Verbesserung des Kaskadenmodells.

1.3.4. Definition von Lebenszyklusphasen.

1.3.5. Grundlegende Arbeit am Projekt.

Literatur.

Einführung

Die industrielle Anwendung von Computern und die wachsende Nachfrage nach Programmen stellen vordringliche Aufgaben für eine deutliche Steigerung der Produktivität der Softwareentwicklung, die Entwicklung industrieller Methoden zur Planung und Gestaltung von Programmen, die Übertragung von organisatorischen, technischen, technischen, wirtschaftlichen und sozialpsychologischen Methoden, Mustern und Methoden aus dem Bereich der materiellen Produktion in den Bereich der Computer. Ein komplexer Ansatz Die Prozesse der Entwicklung, des Betriebs und der Wartung von Software stellen eine Reihe dringender Probleme dar, deren Lösung die "Engpässe" bei der Gestaltung von Programmen beseitigen, die Fertigstellungszeit verkürzen, die Auswahl und Anpassung bestehender Programme verbessern und vielleicht das Schicksal von Systemen mit eingebetteten Computern bestimmen.

In der Praxis der Entwicklung großer Softwareprojekte gibt es oft keine einheitlicher Ansatz auf die Bewertung von Arbeitskosten, Arbeitsbedingungen und Materialkosten, was die Produktivitätssteigerung der Softwareentwicklung und letztendlich das effektive Management des Softwarelebenszyklus behindert. Da ein Programm jeder Art zu einem Produkt wird (mit Ausnahme von Bildungsprogrammen oder Mock-up-Programmen), sollte die Herangehensweise an seine Produktion in vielerlei Hinsicht der Herangehensweise an die Produktion industrieller Produkte ähneln, und Fragen des Softwaredesigns werden äußerst wichtig . Diese Idee liegt B.U. Boehm "Engineering Software Design", die wir beim Verfassen dieser Hausarbeit verwendet haben. In diesem Buch bezieht sich Softwaredesign auf den Prozess der Erstellung eines Designs für ein Softwareprodukt.

1 Softwarelebenszyklus

EINLEITUNG

LCPE ist ein kontinuierlicher Prozess, der mit der Entscheidung über die Notwendigkeit der Softwareerstellung beginnt und mit der vollständigen Außerbetriebnahme endet.

Es gibt mehrere Ansätze, um die Phasen und Aktivitäten des Software-Lebenszyklus (SLLC) zu definieren, Prozessschritte zu programmieren, Wasserfall- und Spiralmodelle. Aber sie alle enthalten gemeinsame grundlegende Komponenten: Problemstellung, Lösungsdesign, Implementierung, Wartung.

Am bekanntesten und vollständigsten ist vielleicht die Struktur des Lebenszyklus nach Böhm, die acht Phasen umfasst. Sie wird später ausführlicher vorgestellt.

Eine der möglichen Optionen kann die Beschreibung der oberen Ebene nach Lehman sein, die drei Hauptphasen umfasst und im allgemeinsten Fall die Beschreibung des Lebenszyklusprogramms darstellt.

Und zur Abwechslung hier die Schritte des Programmierprozesses, die von D. Riley in dem Buch „Using the Modula-2 Language“ vorgestellt werden. Diese Idee ist meiner Meinung nach sehr einfach und vertraut, und wir werden damit beginnen.

1.1 Schritte des Riley-Programmierungsprozesses

Der Programmierprozess umfasst vier Schritte (Abb. 1):

Problemstellung, d.h. eine angemessene Vorstellung davon bekommen, welche Aufgabe das Programm erfüllen soll;

Entwerfen einer Lösung für ein bereits gestelltes Problem (im Allgemeinen ist eine solche Lösung weniger formal als das endgültige Programm);

Programmcodierung, d.h. Übersetzung der entworfenen Lösung in ein Programm, das auf einer Maschine ausgeführt werden kann;

Programmunterstützung, d.h. ein laufender Prozess zur Behebung von Fehlern im Programm und zum Hinzufügen neuer Funktionen.

Reis. 1. Vier Programmierschritte.

Die Programmierung beginnt ab dem Zeitpunkt, an dem Benutzer, d.h. Jemand, der ein Programm braucht, um ein Problem zu lösen, stellt ein Problem Systemanalytiker. Der Benutzer und der Systemanalytiker definieren gemeinsam die Problemstellung. Letztere wird dann übertragen Algorithmist wer für das Design der Lösung verantwortlich ist. Eine Lösung (oder ein Algorithmus) ist eine Abfolge von Operationen, deren Ausführung zur Lösung eines Problems führt. Da der Algorithmus oft nicht für die Ausführung auf einer Maschine geeignet ist, sollte er in ein Maschinenprogramm übersetzt werden. Diese Operation wird vom Codierer durchgeführt. Für nachträgliche Programmänderungen ist der begleitende Programmierer verantwortlich. Und der Systemanalytiker und der Algorithmus und der Programmierer und der begleitende Programmierer – sie alle sind Programmierer.

Bei einem großen Softwareprojekt kann die Anzahl der Benutzer, Systemanalysten und Algorithmen erheblich sein. Darüber hinaus kann es aufgrund unvorhergesehener Umstände erforderlich sein, zu vorherigen Schritten zurückzukehren. All dies ist ein zusätzliches Argument für sorgfältiges Softwaredesign: Die Ergebnisse jedes Schrittes sollten vollständig, genau und nachvollziehbar sein.

1.1.1 Beschreibung des Problems

Einer der wichtigsten Schritte beim Programmieren ist das Setzen eines Problems. Es fungiert als Vertrag zwischen dem Benutzer und dem/den Programmierer(n). Wie ein rechtlich schlecht ausgearbeiteter Vertrag ist ein schlechtes Leitbild nutzlos. Bei einer guten Problemstellung stellen sowohl der Anwender als auch der Programmierer die zu erledigende Aufgabe klar und eindeutig dar, d.h. dabei werden sowohl die Interessen des Benutzers als auch die des Programmierers berücksichtigt. Der Benutzer kann planen, die noch nicht erstellte Software zu verwenden, basierend auf dem Wissen, dass dies möglich ist. Eine gute Formulierung des Problems dient als Grundlage für die Bildung seiner Lösung.

Formulierung des Problems (Programmspezifikation); bedeutet im Wesentlichen eine genaue, vollständige und verständliche Beschreibung dessen, was passiert, wenn ein bestimmtes Programm ausgeführt wird. Der Benutzer betrachtet den Computer normalerweise als Blackbox: Es ist ihm egal, wie der Computer funktioniert, aber es ist wichtig, dass der Computer das kann, was den Benutzer interessiert. Im Mittelpunkt steht die Interaktion zwischen Mensch und Maschine.

Merkmale einer guten Problemstellung:

Genauigkeit, d.h. Ausschluss jeglicher Zweideutigkeit. Es sollte keine Frage geben, was die Ausgabe des Programms für eine gegebene Eingabe sein wird.

Vollständigkeit, d.h. Berücksichtigen aller Optionen für eine gegebene Eingabe, einschließlich fehlerhafter oder unerwarteter Eingaben, und Bestimmen der geeigneten Ausgabe.

Klarheit, d.h. sie sollte sowohl für den Benutzer als auch für den Systemanalytiker verständlich sein, da die Problemstellung der einzige Vertrag zwischen ihnen ist.

Oft stehen die Anforderungen an Genauigkeit, Vollständigkeit und Klarheit im Widerspruch. Viele juristische Dokumente sind daher schwer verständlich, weil sie in einer formalen Sprache verfasst sind, die es Ihnen erlaubt, bestimmte Bestimmungen mit äußerster Präzision zu formulieren und selbst die unbedeutendsten Abweichungen auszuschließen. Beispielsweise sind einige Fragen auf Prüfungsarbeiten manchmal so präzise formuliert, dass der Student mehr Zeit damit verbringt, die Frage zu verstehen, als sie zu beantworten. Darüber hinaus kann es vorkommen, dass der Schüler aufgrund der vielen Details die Hauptbedeutung der Frage überhaupt nicht erfasst. Die beste Problemstellung ist diejenige, die ein Gleichgewicht zwischen allen drei Anforderungen erreicht.

Die Standardform der Problemstellung.

Betrachten Sie die folgende Formulierung des Problems: "Geben Sie drei Zahlen ein und geben Sie die Zahlen der Reihe nach aus."

Eine solche Erklärung genügt den oben genannten Anforderungen nicht: Sie ist weder präzise, ​​noch vollständig, noch verständlich. Sollen die Nummern tatsächlich einzeln pro Zeile oder alle Nummern in einer Zeile eingegeben werden? Bedeutet der Ausdruck „in Reihenfolge“ eine Reihenfolge vom größten zum kleinsten, vom kleinsten zum größten oder dieselbe Reihenfolge, in der sie eingegeben wurden?

Es liegt auf der Hand, dass eine solche Aussage viele Fragen nicht beantwortet. Wenn wir die Antworten auf alle Fragen berücksichtigen, wird die Problemstellung wortreich und schwer verständlich. Daher schlägt D. Riley vor, das Standardformular für die Problemstellung zu verwenden, das maximale Genauigkeit, Vollständigkeit und Klarheit gewährleistet und Folgendes beinhaltet:

Aufgabenname (schematische Definition);

allgemeine Beschreibung (kurze Beschreibung der Aufgabe);

Fehler (ungewöhnliche Eingabemöglichkeiten werden explizit aufgelistet, um Benutzern und Programmierern zu zeigen, welche Maßnahmen die Maschine in solchen Situationen ergreifen wird);

Beispiel (ein gutes Beispiel kann den Kern des Problems vermitteln und verschiedene Fälle veranschaulichen).

Beispiel. Beschreibung des Problems in der Standardform.

TITEL

Sortiere drei ganze Zahlen.

BEZEICHNUNG

Eingabe und Ausgabe von drei ganzen Zahlen, sortiert von der kleinsten zur größten.

Es werden drei ganze Zahlen eingegeben, eine Zahl pro Zeile. In diesem Fall ist eine Ganzzahl eine oder mehrere aufeinanderfolgende Dezimalziffern, denen ein Pluszeichen „+“ oder ein Minuszeichen „-“ vorangestellt sein kann.

Die drei eingegebenen Ganzzahlen werden ausgegeben, wobei alle drei in derselben Zeile angezeigt werden. Benachbarte Zahlen werden durch ein Leerzeichen getrennt. Zahlen werden vom kleinsten zum größten, von links nach rechts angezeigt.

1) Wenn weniger als drei Zahlen eingegeben werden, wartet das Programm auf weitere Eingaben.

Am 1. März 2012 hat die Föderale Agentur für technische Regulierung und Metrologie der Russischen Föderation den GOST R ISO/IEC 12207-2010-Standard „Informationstechnologie. System- und Software-Engineering. Software-Lebenszyklusprozesse“, identisch mit der internationalen Norm ISO/IEC 12207:2008 „System- und Software-Engineering – Software-Lebenszyklusprozesse“.

Dieser Standard legt unter Verwendung etablierter Terminologie einen gemeinsamen Rahmen für die Software-Lebenszyklusprozesse fest, der als Richtlinie in der Softwareindustrie verwendet werden kann. Der Standard definiert die Prozesse, Aktivitäten und Aufgaben, die beim Erwerb eines Softwareprodukts oder einer Dienstleistung sowie bei der Lieferung, Entwicklung, bestimmungsgemäßen Verwendung, Wartung und Abkündigung von Softwareprodukten zum Einsatz kommen.

Software-Lebenszyklusprozesse

Die Norm fasst die verschiedenen Aktivitäten, die während des Lebenszyklus von Softwaresystemen durchgeführt werden können, in sieben Prozessgruppen zusammen. Jeder der Lebenszyklusprozesse innerhalb dieser Gruppen wird in Bezug auf Zweck und gewünschte Ergebnisse, Listen von Aktionen und Aufgaben beschrieben, die durchgeführt werden müssen, um diese Ergebnisse zu erzielen.

• Vereinbarungsprozesse - zwei Prozesse;
• projektorganisatorische Unterstützungsprozesse - fünf Prozesse;
• Projektprozesse - sieben Prozesse;
• technische Prozesse - elf Prozesse;
• Softwareimplementierungsprozesse - sieben Prozesse;
• Softwareunterstützungsprozesse - acht Prozesse;
• Software-Wiederverwendungsprozesse - drei Prozesse.
• Hauptsächlich:
  • Akquisition (Aktionen und Aufgaben des Kunden, der die Software kauft)
  • Lieferung (Tätigkeiten und Aufgaben des Lieferanten, der den Kunden mit einem Softwareprodukt oder einer Dienstleistung beliefert)
  • Entwicklung (Aktionen und Aufgaben des Entwicklers: Erstellen von Software, Erstellen von Design- und Betriebsdokumentationen, Erstellen von Test- und Schulungsmaterialien usw.)
  • Betrieb (Handlungen und Aufgaben des Betreibers – der das System betreibenden Organisation)
  • Wartung (Aktionen und Aufgaben, die von der begleitenden Organisation, dh dem Wartungsdienst, durchgeführt werden). Wartung - Vornehmen von Änderungen an der Software, um Fehler zu beheben, die Leistung zu verbessern oder sich an veränderte Betriebsbedingungen oder Anforderungen anzupassen.
• Hilfs
  • Dokumentation (formalisierte Beschreibung von Informationen, die während des Software-Lebenszyklus erstellt wurden)
  • Konfigurationsmanagement (Anwendung administrativer und technischer Verfahren während des gesamten Softwarelebenszyklus, um den Zustand von Softwarekomponenten zu bestimmen und ihre Änderungen zu verwalten).
  • Qualitätssicherung (sicherstellen, dass das IS und die Prozesse seines Lebenszyklus den festgelegten Anforderungen und genehmigten Plänen entsprechen)
  • Verifizierung (Feststellen, dass Softwareprodukte, die das Ergebnis einer Aktion sind, die Anforderungen oder Bedingungen aufgrund früherer Aktionen vollständig erfüllen)
  • Zertifizierung (Feststellung der Vollständigkeit der Übereinstimmung der spezifizierten Anforderungen und des erstellten Systems mit ihrem spezifischen funktionalen Zweck)
  • Joint Assessment (Beurteilung des Arbeitsstandes am Projekt: Kontrolle der Planung und Verwaltung von Ressourcen, Personal, Ausrüstung, Werkzeugen)
  • Audit (Feststellung der Einhaltung der Anforderungen, Pläne und Vertragsbedingungen)
  • 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
  • Management (Aktivitäten und Aufgaben, die von jeder Partei durchgeführt werden können, die ihre Prozesse verwaltet)
  • Schaffung von Infrastruktur (Auswahl und Pflege von Technologien, Standards und Tools, Auswahl und Installation von Hard- und Software zur Entwicklung, zum Betrieb oder zur Pflege von Software)
  • Verbesserung (Bewertung, Messung, Steuerung und Verbesserung von Lebenszyklusprozessen)
  • Training (Erstausbildung und anschließende Personalentwicklung)

Jeder Prozess umfasst eine Reihe von Aktivitäten. Der Akquisitionsprozess umfasst beispielsweise die folgenden Schritte:

1. Akquisitionseinleitung
2. Erstellung von Angeboten
3. Vorbereitung und Anpassung des Vertrages
4. Lieferantenaufsicht
5. Abnahme und Fertigstellung der Arbeiten

Jede Aktion umfasst eine Reihe von Aufgaben. Die Angebotserstellung sollte beispielsweise Folgendes beinhalten:

1. Bildung von Anforderungen an das System
2. Erstellung einer Liste von Softwareprodukten
3. Konditionen und Vereinbarungen festlegen
4. Beschreibung der technischen Einschränkungen (Systembetriebsumgebung usw.)

Phasen des Softwarelebenszyklus, Beziehung zwischen Prozessen und Phasen

Modell des Software-Lebenszyklus- eine Struktur, die die Reihenfolge der Ausführung und die Beziehung von Prozessen, Aktionen und Aufgaben während des gesamten Lebenszyklus bestimmt. 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.

Die Norm GOST R ISO/IEC 12207-2010 bietet kein spezifisches Lebenszyklusmodell. Seine Bestimmungen gelten für alle Lebenszyklusmodelle, Methoden und Technologien zur Schaffung von geistigem Eigentum. Es beschreibt die Struktur von Lebenszyklusprozessen, ohne anzugeben, wie die in diesen Prozessen enthaltenen Aktivitäten und Aufgaben zu implementieren oder durchzuführen sind.

Das Softwarelebenszyklusmodell umfasst:

1. Stufen;
2. Die Ergebnisse der Arbeit in jeder Phase;
3. Wichtige Ereignisse - Zeitpunkte des Abschlusses der Arbeit und der Entscheidungsfindung.