Technische Dokumentation. Technische Dokumentation Durchführung von Abnahmetests

Anmerkung: Eine logische Fortsetzung des vorherigen Vortrags. Das Problem der praktischen Anwendung von GOST R ISO/IEC 12207 in Organisationen und Projekten wird ausführlich besprochen. In diesem Zusammenhang werden die Standards GOST R ISO/IEC 15271 und GOST R ISO/IEC 16326 untersucht.

Aus der vorherigen Vorlesung sollte klar sein, dass die Umsetzung von GOST R ISO/IEC 12207 eine sehr schwierige Aufgabe ist. Zunächst einmal ist nicht klar, was es bedeutet, „GOST R ISO/IEC 12207 umzusetzen“? Kann es als umgesetzt gelten, wenn einige Prozesse der Organisation mit den Prozessen des Standards übereinstimmen und andere nicht? Kann ein Standard als umgesetzt gelten, wenn einige Projekte danach durchgeführt werden und andere nicht? Diese Liste von Fragen lässt sich endlos fortsetzen.

Es ist kein Zufall, dass im Anschluss an GOST R ISO/IEC 12207 die Norm GOST R ISO/IEC 15271-02 (GOST 15271, 2002) speziell für die Aufgabe ihrer Umsetzung entwickelt wurde, die den Namen „Richtlinien für die Anwendung von GOST“ trägt R ISO/IEC 12207“. Wir werden nun mit der Betrachtung fortfahren.

Standard GOST R ISO/IEC 15271

Die Bedeutung der Norm wird im Einführungsteil erläutert.

„1.2. Nutzer des Standards.

Diese Norm kann von Subjekten (Einzelpersonen, Organisationen) verwendet werden, die GOST R ISO/IEC 12207 bei der Umsetzung von Verträgen anwenden möchten, unabhängig vom Umfang oder der Komplexität des Projekts, durch eine bestimmte Organisation zur Selbstüberwachung oder Verbesserungsarbeit Lebenszyklusprozesse Software-Tools.

Dieser Standard legt fest, wie GOST R ISO/IEC 12207 in Bezug auf verschiedene Arten von Software verwendet werden kann und welche Prozesse für jeden Fall geeignet sind.

Dieser Standard ergänzt GOST R ISO/IEC 12207, das nicht nur ein normatives Dokument, sondern auch ein Standard für die Verwaltung eines realen Projekts ist. (Der letzte Fall tritt beispielsweise auf, wenn GOST R ISO/IEC 12207 ein Modell für die Durchführung eines Teils der Arbeit des Verbesserungsprozesses ist.) Diese Norm sollte als Ganzes gelesen werden, in Einzelfällen können jedoch bestimmte Abschnitte verwendet werden.“

Der GOST R ISO/IEC 15271-Standard besteht aus 8 Abschnitten und 4 Anhängen. Die Inhaltsabschnitte heißen wie folgt (Nummerierung aus dem Text übernommen):

• 4. Grundkonzepte der Entwicklung von GOST R ISO/IEC 12207.
• 5. Implementierung von GOST R ISO/IEC 12207.
• 6. Anwendung in Projekten.
• 7. Anwendung in Organisationen.
• 8. Bewerbung Lebenszyklusmodelle Systeme.

Abschnitt 4 ist im Stil von Kommentaren und Klarstellungen zum Text von GOST R ISO/IEC 12207 verfasst. Die wichtigsten Klarstellungen betreffen das Zusammenspiel von GOST R ISO/IEC 12207 mit Unternehmensstandards der Organisation, die Unterscheidung zwischen den Konzepten „ „Software“ und „System“ und die daraus resultierenden Unterscheidungen zwischen Prozessen im Zusammenhang mit Software und Systemen. Das Konzept wird ausführlich beschrieben Qualitätsmanagement, implementiert in GOST R ISO/IEC 12207. Im Allgemeinen vermittelt der Abschnitt den Eindruck eines kurzen konzeptionellen Überblicks über GOST R ISO/IEC 12207, der an ein Lehrbuch erinnert.

Abschnitt 5 stellt einen allgemeinen Ansatz zur Implementierung vor, der als GOST R ISO/IEC 12207-Implementierungsstrategie bezeichnet wird. Eine Strategie ist gemäß der Norm „eine typische Implementierungsmethode, die befolgt werden sollte, wenn Änderungen an den Aktivitäten oder Projekten einer Organisation vorgenommen werden.“ Die Strategie wird als Projekt umgesetzt, das aus verbindlichen Schritten besteht, die informell beschrieben werden und keinen Bezug zu den Prozessen der Organisation haben. Diese Schritte sind wie folgt:

• a) Entwicklung eines Umsetzungsplans;
• b) praktische Anwendung von GOST R ISO/IEC 12207;
• c) Bereitstellung von Unterstützung Pilotprojekt(S);
• d) Formalisierung der Implementierungsmethode;
• e) Genehmigung der Implementierungsmethode.

Die Entwicklung eines Implementierungsplans umfasst die Festlegung des Anwendungsbereichs von GOST R ISO/IEC 12207. Der Anwendungsbereich kann beispielsweise eine Gruppe von Abteilungen oder Projekten einer Organisation sein. Sie können den Anwendungsbereich auch als eine Reihe von Schlüsselprozessen für die Organisation definieren, die durch Prozesse aus GOST R ISO/IEC 12207 ersetzt werden. Der Implementierungsplan selbst bestimmt die Zusammensetzung der während der Implementierung durchgeführten Projekte (ggf Einige von ihnen). Es versteht sich von selbst, dass bei der Entwicklung eines Umsetzungsplans die notwendigen Ressourcen festgelegt werden: finanzielle, personelle, technische usw.

In der praktischen Anwendung wird erwartungsgemäß vorgeschlagen, den in GOST R ISO/IEC 12207 selbst beschriebenen Anpassungsprozess zu verwenden.

Die Strategie selbst wirft keine Fragen auf – eine solche Abfolge von Schritten kann unter bestimmten Bedingungen sehr effektiv sein, es ist jedoch anzumerken, dass der formale Projektansatz zur Implementierung von GOST R ISO/IEC 12207 auf einem vereinfachten Verständnis der Realität basiert Situation. Angesichts der Tatsache, dass sich die Prozesse einer Organisation (und auch ihre Organisationsstruktur) ständig ändern, halte ich es aus methodischer Sicht für richtiger, die Implementierung einer Norm als fortlaufenden Prozess und nicht als zeitlich begrenztes Projekt zu betrachten. Dieser Prozess überwacht Veränderungen in den Prozessen der Organisation und initiiert einzelne Projekte, zum Beispiel:

• Projekte zur Anwendung von GOST R ISO/IEC 12207;
• ein Projekt zur Schulung aller neuen Mitarbeiter in den Prozessen von GOST R ISO/IEC 12207;
• ein Projekt zur Einführung von Änderungen in implementierten Prozessen im Zusammenhang mit Änderungen in der Organisationsstruktur der Organisation; usw.

Der Ansatz zur Umsetzung von GOST R ISO/IEC 12207 als Prozess, insbesondere wenn er mit seiner Anwendung in Projekten oder einzelnen Abteilungen der Organisation beginnen soll, ermöglicht die Konzentration der Verantwortung für das Gesamtergebnis in den Händen des Prozesseigentümers , wird es möglich sein, ein allgemeines Monitoring von Ergebnissen etc. zu etablieren. Natürlich sollte sich an die Implementierung eine Unterstützung der implementierten Prozesse anschließen, die natürlich auch als Prozess organisiert ist.

Weitere Details zur Verwendung von GOST R ISO/IEC 12207 in Projekten werden im Abschnitt 6 „Anwendung in Projekten“ beschrieben. Der Standard schlägt vor, Projekte zu klassifizieren und führt zu diesem Zweck ein neues Konzept ein – „ Lebenszyklusmodell Systeme“ (eine Liste typischer Modelle finden Sie in Anhang C). Was ein Modell ist, ist nicht formal definiert. Später heißt es in Abschnitt 8: „Das Allgemeine Lebenszyklusmodell Systeme werden in Stufen (Stufen) mit anschließender Anpassung jeder einzelnen davon unterteilt Lebenszyklusmodelle„Spezifisches System“ (im Folgenden finden Sie eine Liste der Stufen). Insgesamt werden drei solcher Modelle betrachtet: Kaskade, inkrementell, evolutionär. Ihre Vor- und Nachteile werden analysiert, und dann werden die Prozesse von GOST R ISO/IEC 12207 „überlagert“. Dadurch erhalten diese Prozesse zusätzliche Eigenschaften, beispielsweise wiederholte Wiederholungen im Lebenszyklus oder zeitliche Überschneidungen mit anderen Prozessen. Darüber hinaus enthält der Abschnitt zahlreiche Empfehlungen mit unterschiedlichem Nutzen für einzelne Hier ein typisches Beispiel.

„6.1.3. Systemeigenschaften

Die Subsysteme und Systemkonfigurationselemente müssen auf der entsprechenden Detailebene definiert werden. Es ist notwendig, die Eigenschaften des Systems zu bestimmen, insbesondere diejenigen, die sich auf die Software beziehen. Bei der Bestimmung dieser Eigenschaften ist zu beachten, welche davon für den Betrieb der Anlage kritisch sind.

Eine indikative Liste von Merkmalen auf Systemebene (die sich auf die Software beziehen und berücksichtigt werden müssen) umfasst:

• Intersystem- und Intrasystem-Schnittstellen;
• Benutzeroberflächen;
• die Auswirkungen von Softwarefehlern auf den Schutz und Systemsicherheit;
• Einschätzung der Rechenleistung und Zeitbeschränkungen;
• Verfügbarkeit technisch umgesetzter Programme;
• Verfügbarkeit geeigneter Computer.

Wenn ein System viele Subsysteme oder Konfigurationselemente umfasst, müssen diese vollständig durch Arbeit auf Systemebene aus dem Entwicklungsprozess abgedeckt werden. Sämtliche Anforderungen an Schnittstellen und Aufbau (Integration) von Systemen müssen berücksichtigt werden. Für ein kleines System ist eine so strenge Abfolge von Aktionen möglicherweise nicht erforderlich.“

Die ungefähre und vage Formulierung in der obigen Passage ist charakteristisch für die gesamte Norm als Ganzes.

Der zentrale Teil des sehr kurzen Abschnitts 7 „Anwendung in Organisationen“ ist der folgende Text.

„7.2. Anwendungsmöglichkeiten

Die Gründe, warum GOST R ISO/IEC 12207 in Organisationen implementiert wird, können folgende sein:

• Überprüfung der Perfektion einer bestehenden Methode. Dies ist in der Regel der Fall, wenn die Methode von der Organisation selbst entwickelt wurde oder eine bestehende Methode ausgewählt und modifiziert wurde;
• praktische Anwendung dieser Methode zur Vermeidung von Risiken im Zusammenhang mit dem Eintritt in neue Marktsektoren mit strengeren Anforderungen, die mit potenziellen Risiken verbunden sind;
• Entwicklung einer neuen Methode, beispielsweise um den Anforderungen einer neuen Organisation gerecht zu werden. Organisationen, die durch eine Fusion oder geschäftliche Zusammenarbeit entstanden sind, können abgedeckt sein. Dies kann erforderlich sein, um einige Prozessmodelle für die Erbringung spezifischer Arbeiten zu unterstützen;
• Verwalten der Implementierung neuer Technologien, beispielsweise die Automatisierung manueller Prozesse oder die Änderung der Methoden zur Implementierung eines Softwareprodukts. GOST R ISO/IEC 12207 legt Kriterien fest, mit denen die Exzellenz der jeweiligen Methode vor oder nach einem Technologiewechsel überwacht werden kann;
• Einschätzung der internen Fähigkeiten der Partei im Hinblick auf die Erfüllung der Vertragskriterien, beispielsweise als Partei, die am Ausschreibungsverfahren teilnimmt;
• Identifizierung von Meilensteinen, die zur Entwicklung fortgeschrittenerer Programme führen können, wie z. B. Auditierung gemäß GOST R ISO/IEC 12207 und Nutzung des Verbesserungsprozesses selbst.“

Selbst wenn keine sachlichen Einwände vorliegen, ist es immer noch unmöglich, diesen Text als Standard zu betrachten. Es ähnelt vor allem einem Schulungshandbuch und wird als solches wahrscheinlich gefragt sein, aber ein solcher Text kann nicht als Handlungsleitfaden für die Umsetzung von GOST R ISO/IEC 12207 in einer Organisation verwendet werden.

Abschließend Abschnitt 8 „Antrag Lebenszyklusmodelle Systeme" enthält eher vage Definitionen" Lebenszyklusmodelle Systeme“ und „ Lebenszyklusmodelle Software“ und versucht, einen Zusammenhang zwischen ihnen herzustellen. Da es keine genauen Definitionen gibt, ist eine Beurteilung der Ergebnisse nicht möglich.

Im Allgemeinen erweckt die Norm GOST R ISO/IEC 15271 den Eindruck, ein reines Hilfsdokument in Bezug auf GOST R ISO/IEC 12207 zu sein, das an Ungenauigkeiten und einer Fülle an Gemeinplätzen leidet. Für praxisorientierte Manager ist es ungeeignet – es gibt zu viel abstrakte Argumentation und zu wenig Spezifität. Für Studenten und Spezialisten, die sich mit IT-Managementprozessen befassen, mangelt es an einem umfassenden Überblick über das Thema (schließlich wird es durch GOST R ISO/IEC 12207 eingeschränkt) und es ist mit unnötigen technischen Details überladen. Dennoch ist die Kenntnis von GOST R ISO/IEC 15271 nützlich, da es die Denkrichtung von Spezialisten im Bereich IT-Management aufzeigt und zeigt, wo und wie sich moderne Standards entwickeln. Ich würde es als vorläufiges Arbeitsdokument betrachten, zwar in Form eines Standards, aber eher für die Diskussion mit einem interessierten Publikum von IT-Management-Spezialisten gedacht.

Standard GOST R ISO/IEC 16326

Ein weiterer Versuch, den Prozess der Anwendung von GOST R ISO/IEC 12207 zu formalisieren, wurde in der Norm GOST R ISO/IEC 16326 „Richtlinien für die Verwendung von GOST R ISO/IEC 12207 im Projektmanagement“ (GOST 16326, 2002) unternommen. Es zeigt einen Versuch der Vereinigung Lebenszyklusprozesse von GOST R ISO/IEC 12207 mit Projektmanagementprozessen aus dem beliebten methodischen Nachschlagewerk PMBOK 1 PMBOK – Projektmanagement-Wissensbestand(PMBOK, 2009) und der ISO 10006-Standard (die russische Version des Standards ist in (GOST 10006, 2005) enthalten). Dies ist schematisch in Abb. dargestellt. 4.1 in der Norm angegeben.

Reis. 4.1.

Der Nutzerkreis des Standards ist in Abschnitt 1.1 recht genau definiert.

„1.1. Nutzerkreis

Dieser Standard richtet sich an Unternehmen, die GOST R ISO/IEC 12207 in Softwareprojekten verwenden oder dies planen, unabhängig von Umfang, erstellten Produkten, Methodik, Umfang oder Komplexität. Der Standard richtet sich in erster Linie an Projektadministratoren, die für die Einhaltung von Managementprozessen mit GOST R ISO/IEC 12207 verantwortlich sind:

• Administratoren, die für die Organisation und kontinuierliche Verbesserung verantwortlich sind Lebenszyklusprozesse Software gemäß GOST R ISO/IEC 12207;
• Administratoren, die für die Anwendung verantwortlich sind Lebenszyklusprozesse Software gemäß GOST R ISO/IEC/12207 auf Designebene;
• Organisationen oder Personen, die Subunternehmer bei der Umsetzung von SCP sind ( Software-Projektmanagement. - AB).

Zu den Überlegungen für Einzelpersonen gehören:

• an Softwareprojekten beteiligt, jedoch nicht an AP ( Projektadministratoren. - AB);
• die Administratoren von Nicht-Software-Projekten sind, aber mit AP-Software verbunden sind.“

Der relativ kurze Haupttext (Abschnitt 6 „Leitfaden“ nimmt nur 9 von insgesamt 35 Seiten ein) ist ein fortlaufender Kommentar zum Prozess 7.1 „Management“ von GOST R ISO/IEC 12207 aus PMBOK-Sicht. Der Kommentarstil ist informell, die Argumente haben meist beratenden Charakter. Der Kommentar geht nicht über den normalen gesunden Menschenverstand hinaus und enthält nichts Neues. Im Allgemeinen ist dies eine nützliche Lektüre für Projektmanager (in der Terminologie der Übersetzer „Administratoren“), aber nichts weiter.

Anhang A ist eine große Tabelle, die die Zusammenhänge zwischen den Hauptprozessen von GOST R ISO/IEC 12207 und den daraus abgeleiteten Aktivitäten des Prozesses „Management“ zeigt. Alle diese Links sind im Hauptteil der Norm GOST R ISO/IEC 12207 enthalten; Durch die Zusammenfassung in einer Tabelle werden keine neuen Informationen hinzugefügt.

Anhang B ist genau die gleiche Tabelle, die Prozessbereiche und einzelne Prozesse aus dem PMBOK mit den Aktivitäten des „Management“-Prozesses aus GOST R ISO/IEC 12207 verknüpft.

Eine ähnliche Tabelle, in der anstelle von Bereichen Prozessgruppen im PMBOK-Sinn verwendet werden, finden Sie in Anhang C. Die Anhänge B und C fassen eigentlich alles zusammen, was in Abschnitt 6 des Standards gesagt wurde. Warum dies in Tabellenform dargestellt werden musste, ist unklar. Diese Tabellen liefern keine zusätzlichen Informationen, sondern belegen lediglich die Tatsache, dass es Verbindungen zwischen PMBOK und GOST R ISO/IEC 12207 gibt. Der Status beider Anhänge ist jedoch „Referenz“, sodass sie möglicherweise keinen unabhängigen Wert hatten.

Eine weitere zusammenfassende Tabelle finden Sie in Anhang D. Sie zeigt die Beziehungen zwischen drei Quellen: GOST R ISO/IEC 12207, PMBOK und dem ISO 10006-Standard. Ich möchte sofort feststellen, dass letzterer erst 2005 ins Russische übersetzt wurde. Infolgedessen unterscheidet sich die in Anhang D der Norm GOST R ISO/IEC 16326 2002 verwendete Terminologie von der späteren. Wie in früheren Fällen ist unklar, welche Bedeutung die Darstellung dieser Beziehungen in kompakter tabellarischer Form hat. Darüber hinaus übersteigt der Gesamtumfang der Anhänge A-D den Umfang des Hauptteils 6 „Handbuch“ um mehr als das Doppelte.

Meiner Meinung nach unterscheidet sich GOST R ISO/IEC 16326-2002 in Form und Zweck nicht von GOST R ISO/IEC 15271-2002. Beide leiden unter einem Übermaß an Argumentation, die „im Großen und Ganzen“ richtig ist und nur auf dem gesunden Menschenverstand basiert. Diese Argumente sind für jeden, der über praktische Erfahrung im Projektmanagement verfügt, offensichtlich und erscheinen für diejenigen, die keine solche Erfahrung haben, kaum vernünftig. Im Gegensatz zu GOST R ISO/IEC 15271-2002 ist die Norm GOST R ISO/IEC 16326-2002 formaler, die praktische Bedeutung des vorgeschlagenen Formalismus ist jedoch nicht klar.

Aus Sicht der praktischen Anwendung bei der Gestaltung IT-bezogener Geschäftsprozesse sind beide Standards weitgehend nutzlos. Andererseits können sie bei der Umsetzung komplexer Projekte gefragt sein, die neben einem Studium der IT-Managementpraktiken auch eine Analyse des Projektmanagements usw. umfassen Qualitätsmanagement.

Zusätzlich zu den oben besprochenen hat GOST R ISO/IEC 12207 eine Reihe von Standards hervorgebracht, die die darin enthaltenen Standards detailliert beschreiben Lebenszyklusprozesse. Dazu gehören beispielsweise GOST R ISO/IEC 15910-2002 „Der Prozess der Erstellung von Benutzerdokumentation für Software“ (GOST 15910, 2002) und GOST R ISO/IEC 14764-2002 „Wartung von Software“ (GOST 14764, 2002). . Einige ähnliche ISO-Standards wurden noch nicht ins Russische übersetzt; Es ist wahrscheinlich, dass die Zahl der russischsprachigen GOST R ISO-Standards, die in direktem Zusammenhang mit GOST R ISO/IEC 12207 stehen, in Zukunft zunehmen wird.

Basislinie gemäß GOST R ISO/IEC 12207-2010

oder die formal überprüft wurden und anschließend als Grundlage für die weitere Entwicklung dienen und die nur durch offizielle und kontrollierte Änderungen geändert werden können [aus Abschnitt 4.6 von GOST R ISO/IEC 12207-2010]

Validierung gemäß GOST R ISO/IEC 12207-2010

Bestätigung (basierend auf der Vorlage objektiver Beweise), dass der beabsichtigte Zweck bzw. die beabsichtigte Anwendung durchgeführt wurde. Hinweis – Bei der Validierung im Kontext handelt es sich um eine Reihe von Maßnahmen, die garantieren und Vertrauen schaffen, dass sie ihren aktuellen und zukünftigen Zweck erfüllen können [aus Abschnitt 4.54 von GOST R ISO/IEC 12207-2010]

Verifizierung gemäß GOST R ISO/IEC 12207-2010

Bestätigung (basierend auf der Bereitstellung objektiver Nachweise), dass die festgelegten Anforderungen vollständig erfüllt wurden. HINWEIS Bei der Überprüfung im Kontext handelt es sich um eine Reihe von Aktionen, die ein Lebenszyklusergebnis mit den erforderlichen Merkmalen für dieses Ergebnis vergleicht. Die Ergebnisse des Lebenszyklus können (ohne darauf beschränkt zu sein) spezifizierte Anforderungen, Beschreibungen und direkt sein [aus Abschnitt 4.55 von GOST R ISO/IEC 12207-2010]

Qualitätssicherung nach GOST R ISO/IEC 12207-2010

Alle geplanten und systematischen Aktivitäten werden innerhalb des Rahmens durchgeführt und in angemessener Weise nachgewiesen, um ausreichendes Vertrauen zu schaffen, dass der Kunde voll und ganz zufrieden ist. Anmerkungen:

1. Es gibt sowohl interne als auch externe Qualitätsgarantien:
   1. interne Qualitätssicherung: schafft im Rahmen der Qualitätssicherung Vertrauen;
   2. Externe Qualitätssicherung: In Vertragssituationen schafft Qualitätssicherung Vertrauen gegenüber anderen.
2. Einige Qualitätssicherungs- und Qualitätssicherungsaktivitäten hängen miteinander zusammen.
3. Solange die Qualitätsanforderungen nicht vollständig den Bedürfnissen entsprechen, kann die Qualitätssicherung nicht die erforderliche Sicherheit bieten.

[aus Abschnitt 4.34 GOST R ISO/IEC 12207-2010]

5.2.2 Zusammenfassung der Lebenszyklusprozesse

In dieser Norm gibt es zwei wichtige Prozessbereiche. Abschnitt 6 liefert den Systemkontext für den Betrieb eines eigenständigen Softwareprodukts oder einer eigenständigen Dienstleistung oder eines Softwaresystems. Abschnitt 7 enthält spezifische Softwareprozesse zur Verwendung bei der Implementierung eines Softwareprodukts oder einer Softwaredienstleistung, die ein Element eines größeren Systems ist.

Um die gleichzeitige Verwendung dieser Internationalen Norm zu erleichtern, erhalten die entsprechenden Prozesse von Abschnitt 6 die gleichen Unterabschnittsbezeichnungen.

Im Allgemeinen sind die in dieser Norm vorgestellten Prozesse auf die Software bzw. Eingaben zu den Ergebnissen der vorgesehenen Prozesse zugeschnitten. Viele Prozesse ähneln softwarespezifischen Prozessimplementierungen, weisen jedoch wichtige Unterschiede hinsichtlich Zielen, Ergebnissen und Zielgruppen auf. Benutzer dieser Norm und dieser Norm sollten unbedingt die Erläuterungen und Hinweise in jedem dieser spezifischen Prozesse lesen.

Vereinbarungsprozesse definieren die Aktivitäten, die zur Entwicklung von Vereinbarungen zwischen zwei Organisationen erforderlich sind. Wenn ein Akquiseprozess implementiert wird, bietet er die Möglichkeit, Geschäfte mit dem Lieferanten der im Rahmen des Projekts entwickelten Produkte, die für die Verwendung im Betriebssystem, Systemunterstützungsleistungen oder Systemelementen bereitgestellt werden, abzuwickeln. Wenn ein Lieferprozess implementiert wird, bietet er die Möglichkeit, ein Projekt durchzuführen, bei dem das Ergebnis ein Produkt oder eine Dienstleistung ist, die an die erwerbende Partei geliefert wird.

Daher zielen die in dieser Norm angegebenen Vereinbarungsprozesse auf Software-Vereinbarungsprozesse von ab.

Organisatorische Projektunterstützungsprozesse verwalten die Fähigkeit von Organisationen, Produkte oder Dienstleistungen durch Projektinitiierung, -unterstützung und -management zu erwerben und bereitzustellen. Diese Prozesse stellen die Ressourcen und die Infrastruktur bereit, die zur Unterstützung von Projekten erforderlich sind, und stellen sicher, dass organisatorische Ziele und festgelegte Vereinbarungen erreicht werden. Sie erheben nicht den Anspruch, eine vollständige Reihe von Geschäftsprozessen zu sein, die die Verwaltung der Geschäftsaktivitäten einer Organisation umsetzen.

Zu den organisatorischen Unterstützungsprozessen des Projekts gehören:

a) Lebenszyklusmodell-Managementprozess;

B) Infrastrukturmanagementprozess;

c) Projektportfoliomanagementprozess;

d) Personalmanagementprozess;

e) Qualitätsmanagementprozess.

Im Allgemeinen handelt es sich bei den in dieser Norm vorgesehenen projektorganisatorischen Unterstützungsprozessen um Prozesse, die sich auf Software aus dem entsprechenden Prozesssatz in konzentrieren.

In dieser Norm wird das Projekt als Grundlage für die Beschreibung der Prozesse im Zusammenhang mit Planung, Bewertung und Steuerung gewählt. Die mit diesen Prozessen verbundenen Prinzipien können auf jeden Bereich des Organisationsmanagements angewendet werden.

Es gibt zwei Kategorien von Projektprozessen. Projektmanagementprozesse werden verwendet, um den Fortschritt eines Projekts zu planen, auszuführen, zu bewerten und zu verwalten. Projektunterstützungsprozesse stellen sicher, dass spezielle Managementziele erreicht werden. Im Folgenden werden beide Kategorien von Projektprozessen beschrieben.

Projektmanagementprozesse werden verwendet, um Projektpläne zu erstellen und zu entwickeln, den tatsächlichen Fortschritt und den Fortschritt anhand von Plänen zu bewerten und den Projektfortschritt bis zum Abschluss zu verwalten. Einzelne Projektmanagementprozesse können jederzeit im Lebenszyklus und auf jeder Ebene der Projekthierarchie als Reaktion auf Projektpläne oder das Eintreten unvorhergesehener Ereignisse aufgerufen werden. Projektmanagementprozesse werden je nach Risiko und Komplexität des Projekts auf einem strengen und formalisierten Niveau angewendet:

a) Projektplanungsprozess;

b) der Projektmanagement- und Bewertungsprozess.

Projektunterstützungsprozesse bilden einen spezifischen Aufgabenkomplex, der auf die Erreichung spezifischer Managementziele abzielt. Alle diese Prozesse sind bei der Verwaltung jeder initiierten Aktivität offensichtlich und reichen von der Organisation als Ganzes bis hin zu einem separaten Lebenszyklusprozess und seinen Aufgaben:

a) Entscheidungsmanagementprozess;

b) Risikomanagementprozess;

c) Konfigurationsmanagementprozess;

d) Informationsmanagementprozess;

e) Messvorgang.

Im Allgemeinen sind die in dieser Norm dargestellten Projektunterstützungsprozesse mit den in aufgeführten Projektunterstützungsprozessen identisch, mit Ausnahme einiger Unterschiede in der Form ihrer Darstellung. In einigen Fällen können Software-Support-Prozesse Beziehungen zu Projekt-Support-Prozessen aufweisen.

Technische Prozesse werden verwendet, um Systemanforderungen zu definieren, die Anforderungen in ein nützliches Produkt umzuwandeln, das fortlaufende Kopieren des Produkts zu ermöglichen (sofern erforderlich), das Produkt anzuwenden, die erforderlichen Dienste bereitzustellen, die Bereitstellung dieser Dienste aufrechtzuerhalten und das Produkt aus dem Verkehr zu ziehen, wenn sie werden nicht für die Erbringung der Dienstleistung verwendet.

Technische Prozesse definieren die Aktivitäten, die es ermöglichen, organisatorische und gestalterische Funktionen umzusetzen, um den Nutzen zu optimieren und die Risiken zu reduzieren, die sich aus technischen Entscheidungen und Maßnahmen ergeben. Durch diese Aktivitäten können Produkte und Dienstleistungen die Merkmale Aktualität und Verfügbarkeit, Kosteneffizienz, Funktionalität, Zuverlässigkeit, Wartbarkeit, Produktivität, Anpassungsfähigkeit und andere Qualitätsmerkmale aufweisen, die von erwerbenden und unterstützenden Organisationen gefordert werden. Es ermöglicht auch, dass Produkte und Dienstleistungen zivilrechtliche Erwartungen oder Anforderungen erfüllen, einschließlich Gesundheits-, Sicherheits- und Umweltfaktoren.

Technische Prozesse bestehen aus folgenden Prozessen:

a) Ermittlung der Anforderungen der Rechteinhaber (ein Sonderfall des Prozesses zur Ermittlung der Anforderungen der Rechteinhaber nach);

b) Systemanforderungsanalyse (ein Sonderfall des Anforderungsanalyseprozesses);

C) Systemarchitekturentwurf (ein Sonderfall des Architekturentwurfsprozesses gemäß);

D) Implementierungsprozess (ein Sonderfall des Systemelement-Implementierungsprozesses, der in Abschnitt 7 dieser Norm als Software-Implementierungsprozess beschrieben und weiterentwickelt wird);

e) Systemintegrationsprozess (ein Sonderfall des Integrationsprozesses gemäß);

f) der Systemqualifikationstestprozess (ein Prozess, der dazu beiträgt, die Ergebnisse des Verifizierungsprozesses nach ) zu erreichen;

G) der Softwareinstallationsprozess (der Prozess, der dazu beiträgt, die Ergebnisse des in beschriebene Übertragungsprozesses zu erreichen);

H) Software-Akzeptanzunterstützungsprozess (der Prozess, der zum Erreichen der Ergebnisse des in beschriebene Übertragungsprozesses beiträgt);

i) der Software-Betriebsprozess (ein Sonderfall des in);

j) Softwarewartungsprozess (ein Sonderfall des in );

k) der Prozess der Software-Entnahme aus dem Verkehr (ein Sonderfall des Prozesses der Entnahme und Abschreibung gemäß Abschnitt).

Generell handelt es sich bei den in dieser Norm dargestellten technischen Prozessen um softwareorientierte Sonderfälle bzw. um Beiträge zu den Ergebnissen der in vorgestellten technischen Prozesse. Die meisten von ihnen ähneln Software-Implementierungsprozessen, weisen jedoch wichtige Unterschiede auf. Beispielsweise beginnen die Systemanforderungsanalyse und die Softwareanforderungsanalyse mit unterschiedlichen Ausgangspunkten und verfolgen unterschiedliche Zwecke.

Mithilfe von Swird ein bestimmtes Systemelement (Komponente) in Form eines Softwaretools erstellt. Diese Prozesse wandeln spezifizierte Verhaltensweisen, Schnittstellen und Implementierungsbeschränkungen in Aktionen um, die zu einem Systemelement führen, das die aus den Systemanforderungen abgeleiteten Anforderungen erfüllt.

Ein besonderer Prozess ist der Prozess der Softwareimplementierung, der ein spezifisches Softwaremerkmal des Implementierungsprozesses ausdrückt.

Der Softwareimplementierungsprozess umfasst mehrere spezielle Prozesse auf niedrigerer Ebene:

a) der Prozess der Analyse von Softwareanforderungen;

B) Entwurfsprozess der Softwarearchitektur;

c) der detaillierte Software-Designprozess;

d) Software-Designprozess;

e) Software-Integrationsprozess;

f) Software-Qualifizierungstestprozess.

Software-Support-Prozesse stellen eine spezifisch fokussierte Reihe von Aktivitäten dar, die auf die Ausführung eines speziellen Softwareprozesses abzielen. Jeder unterstützende Prozess unterstützt den Prozess der Softwareimplementierung als Ganzes mit einem bestimmten Zweck und trägt zum Erfolg und zur Qualität des Softwareprojekts bei. Es gibt acht solcher Prozesse:

a) Softwaredokumentationsverwaltungsprozess;

b) Softwarekonfigurationsverwaltungsprozess;

c) Software-Qualitätssicherungsprozess;

d) Software-Verifizierungsprozess;

e) Softwarevalidierungsprozess;

f) Software-Audit-Prozess;

g) Software-Audit-Prozess;

H) der Prozess der Lösung von Problemen in Software.

Die Software-Wiederverwendungsprozessgruppe besteht aus drei Prozessen, die die Fähigkeit einer Organisation unterstützen, Softwarekomponenten über Projektgrenzen hinweg wiederzuverwenden. Diese Prozesse sind einzigartig, da sie naturgemäß außerhalb der Grenzen eines bestimmten Projekts eingesetzt werden.

Software-Wiederverwendungsprozesse sind:

a) Domain-Design-Prozess;

b) Prozess zur Verwaltung der Wiederverwendung von Vermögenswerten;

C) der Prozess zur Verwaltung der Programmwiederverwendung.

1) Ermöglicht die Implementierung eines beliebigen Lebenszyklusmodells- das ist möglich, weil Der Standard bietet eine Möglichkeit, die Reihenfolge der Ausführung von Prozessen und Aufgaben zu definieren, wobei ein Prozess einen anderen Prozess oder Teile davon aufrufen kann.

2) Bietet maximale Flexibilität– Viele Prozesse und Aufgaben sind so gestaltet, dass sie an spezifische IS-Projekte angepasst werden können. Bei der Anpassung geht es darum, Prozesse, Aktivitäten und Aufgaben zu eliminieren, die auf ein bestimmtes Projekt nicht anwendbar sind.

3) Eine Beschreibung konkreter Wirkungsweisen enthält die Norm grundsätzlich nicht, insbesondere Rohlinge, Lösungen oder Dokumentationen, beschreibt es lediglich die Architektur von Software-Lebenszyklusprozessen, spezifiziert jedoch nicht im Detail, wie die in den Prozessen enthaltenen Aufgaben auszuführen oder umzusetzen sind.

4) Der Standard enthält nur sehr wenige Beschreibungen zum Datenbankdesign- das ist berechtigt, denn Unterschiedliche IS- und unterschiedliche Softwaresysteme können nicht nur bestimmte Datenbanktypen verwenden, sondern auch überhaupt keine Datenbanken verwenden.

5) Der Wert des Standards besteht darin, dass er enthält Aufgabenstellungen, Qualitätsmerkmale, Bewertungskriterien etc. und bietet eine umfassende Abdeckung von Designlösungen.

6) Obwohl der Standard nicht die Verwendung eines bestimmten Lebenszyklusmodells oder einer bestimmten Entwicklungsmethode vorschreibt, legt er fest, dass die Projektparteien für Folgendes verantwortlich sind:

Auswahl eines Lebenszyklusmodells für das zu entwickelnde Projekt;

Anpassung der Prozesse und Aufgaben des Standards an das gewählte Modell;

Auswahl und Anwendung von Softwareentwicklungsmethoden;

Durchführen von Aktivitäten und Aufgaben, die für ein bestimmtes Softwareprojekt geeignet sind.

GOST 34 komplexe Standards.

Es wurde als umfassender Satz miteinander verbundener sektorübergreifender Dokumente konzipiert.

Objekte der Standardisierung: automatisierte Systeme verschiedener Art und alle Arten ihrer Komponenten.

GOST-Standards sehen die Phasen und Phasen der Arbeit zur Schaffung eines automatisierten Systems vor, sehen jedoch nicht explizit End-to-End-Prozesse vor, die während der Implementierung des Lebenszyklus stattfinden.

Laut GOST gliedert sich die Entwicklung eines automatisierten Systems in folgende Schritte und Phasen:

Bühne 1 Bildung von Anforderungen an Redner:

Stufe a: Inspektion der Anlage und Begründung der Notwendigkeit, ein automatisiertes System zu entwickeln;

Stufe b: Bildung von Kundenanforderungen an ein automatisiertes System;

Stufe c: Erstellung eines Berichts über die geleistete Arbeit und Vorbereitung eines Antrags auf Ausarbeitung technischer Spezifikationen.

Stufe 2 Konzeptentwicklung:

a: Untersuchung des Objekts;

b: Durchführung der notwendigen Recherchen;

c: Entwicklung von Optionen für das KKW-Konzept, das den Kundenanforderungen gerecht wird;

d: Erstellung eines Berichts über die geleistete Arbeit.

Stufe 3 Entwicklung und Genehmigung technischer Spezifikationen für den Bau von Kernkraftwerken.

Stufe 4 Entwicklung eines vorläufigen Entwurfs des KKW:

a: Entwicklung vorläufiger Designlösungen für das gesamte System als Ganzes und für seine einzelnen Komponenten;

b: Entwicklung der Dokumentation.

Stufe 5 technische Projektentwicklung:

a: Entwicklung von Designlösungen für das Gesamtsystem und seine Teile;

b: Entwicklung der Dokumentation für das automatisierte System und die darin enthaltenen Subsysteme;

c: Entwicklung und Ausführung von Dokumentationen für die Lieferung von Produkten zur Fertigstellung von Kernkraftwerken oder Entwicklung und Ausführung technischer Anforderungen für die Entwicklung dieser Produkte.

Stufe 6 Entwicklung technischer Dokumentation:

a: Entwicklung der Arbeitsdokumentation für den Systemteil;

b: Softwareentwicklung oder -anpassung.

Stufe 7Inbetriebnahme des entwickelten Systems:

a: Vorbereiten des Automatisierungsobjekts für die Implementierung automatisierter Systeme;

b: Personalschulung;

c: Ausstattung der Lautsprecher mit Soft- und Hardware;

d: Installationsarbeiten;

d: Inbetriebnahme;

e: Vorversuche;

g: Probebetrieb;

h: Abnahmetests.

Stufe 8 begleiten:

a: Ausführung der Arbeiten gemäß Gewährleistungspflichten;

b: Service nach Ablauf der Garantie.