Dokumente zur GOST-Software. GOST-Standard für Softwaredokumentation. Allgemeine Merkmale der Erkrankung

ein System Softwareproduktdokumentation – ESPD – gehört zur GOST-Klasse 19 und ist in 10 Gruppen unterteilt:
1. Grundlegende Standards.
2. Regeln für die Ausführung der Entwicklungsdokumentation.
3. Regeln für die Ausführung der Fertigungsdokumentation.
4. Regeln für die Umsetzung der Supportdokumentation.
5. Regeln für die Umsetzung der Betriebsdokumentation.
6. Umlaufregeln Programmdokumentation.

Standardnummer 0 enthält allgemeine Bestimmungen Die Normen 7 und 8 sind vorbehalten und Nummer 9 umfasst weitere Normen, die nicht in den ersten 6 enthalten sind.

Das kurze Beschreibungen GOST-Klasse 19; detailliertere Informationen finden Sie in den Nachschlagewerken.

GOST 19.001-77 – ein einheitliches System der Programmdokumentation.
GOST 19.101-77 – Arten von Programmen und Programmunterlagen.
GOST 19.102-77 – Entwicklungsstadien von Programmen und Programmdokumentation.
GOST 19.105-78 – Anforderungen an die Gestaltung von Programmdokumenten, Komplexen und Systemen, unabhängig von ihrem Zweck und Umfang. GOST 19.105-78 enthält volle Liste Dokumentation, die dem abgeschlossenen Dokument beiliegen sollte Software.

Liste der nach GOST 19.105-78 deklarierten Dokumentation:

1. Dokumente, die Informationen enthalten, die für die Entwicklung eines Softwareprodukts und seine Herstellung erforderlich sind.
1.1. Spezifikation – die Zusammensetzung des Programms und seiner Dokumentation.
1.2. Liste der Originalinhaber – eine Liste der Unternehmen, in denen die Originaldokumentation des Programms aufbewahrt wird.
1.3. Programmtext – Erfassen Sie den Programmtext mit den erforderlichen Kommentaren.
1.4. Programmbeschreibung – Informationen über den logischen und funktionalen Aufbau des Programms.
1.5. Testprogramm und -methodik – Anforderungen, die beim Testen des Programms, des Verfahrens und der Methoden zu deren Kontrolle überprüft werden müssen.
1.6. Leistungsbeschreibung – Zweck und Anwendungsbereich des Programms, technische und besondere Anforderungen, notwendige Entwicklungsstufen und -bedingungen, Testarten.

1.7. Erläuterung – Algorithmusdiagramm, allgemeine Beschreibung des Algorithmus, vom Programm ausgeführte Funktion. Erläuterung der getroffenen technischen Entscheidungen.

2. Dokumente, die beim Betrieb des Softwareprodukts verwendet werden.
Liste der operativen Dokumente – eine Liste der operativen Dokumente für das Programm.
Form – Hauptmerkmale des Programms, Vollständigkeit, allgemeine Informationenüber die Nutzung des Programms.
Beschreibung der Anwendung – Informationen über den Zweck des Programms, Anwendungsbereich, Klasse der zu lösenden Aufgaben, Nutzungsbeschränkungen, erforderliche Hardwarekonfiguration.
Systemprogrammiererhandbuch – Informationen zur Überprüfung und Sicherstellung der Funktionalität sowie zur Einrichtung des Programms.
Programmierhandbuch – Informationen zum Betrieb des konfigurierten Programms.
Bedienerhandbuch – Informationen zur Sicherstellung des Verfahrens zur Kommunikation zwischen Bediener und Computer während der Programmausführung.
Sprachbeschreibung – Beschreibung der Syntax und Semantik der im Programm verwendeten Sprache.
Führung Wartung– Informationen zum Einsatz von Testprogrammen bei der Wartung technischer Geräte.

Andere GOSTs Klasse 19:

GOST 19.201-78 – das Verfahren zur Erstellung und Vorbereitung technischer Spezifikationen für die Entwicklung eines Programms oder Softwareprodukts.
GOST 19.202-78 – Form und Verfahren zur Erstellung von Spezifikationen für Softwareprodukte gemäß GOST 19.101-77.
GOST 19.301-79 – Programm und Methodik zum Testen von Softwareprodukten.
GOST 19.401-78 – das Verfahren zum Erstellen und Formatieren von Programmtexten bei der Entwicklung von Softwareprodukten.
GOST 19.402-78 – Beschreibung des Programms.
GOST 19.403-79 – Form der Vervollständigung und Inhalt der Liste der ursprünglichen Inhaber, definiert in GOST 19.105-78.
GOST 19.404-79 – Form der Vervollständigung und Inhalt der Erläuterung, definiert in GOST 19.105-78.
GOST 19.501-78 – Form des Ausfüllens und Inhalt des Formulars für ein Softwareprodukt, definiert in GOST 19.105-78.
GOST 19.502-78 – Ausfüllform und Inhalt der Anwendungsbeschreibung gemäß GOST 19.105-78.
GOST 19.503-79 – Form und Inhalt des Systemprogrammiererhandbuchs, definiert in GOST 19.105-78.
GOST 19.504-79 – Form der Fertigstellung und Inhalt des Programmierhandbuchs, definiert in GOST 19.105-78.
GOST 19.505-79 – Form der Ausfüllung und Inhalt der Bedienungsanleitung, definiert in GOST 19.105-78.
GOST 19.506-79 – Form der Vervollständigung und Inhalt der Beschreibung der in GOST 19.105-78 definierten Sprache.
GOST 19.507-79 – Form der Ausfüllung und Inhalt der Liste der Betriebsdokumente, definiert in GOST 19.105-78.
GOST 19.508-79 – Form der Ausfüllung und Inhalt des Wartungshandbuchs, definiert in GOST 19.105-78.
GOST 19.701-90 – Diagramme von Algorithmen, Programmen, Daten und Systemen.

Das Hauptziel dieses Textes besteht darin, zu erklären, was das Unified System of Program Documentation (USPD) ist und wie diese Standards in der Praxis angewendet werden können. Ich beginne mit einer Geschichte darüber, welche Standards es gibt, und schließe mit der Erfahrung ab, die einzelnen ESPD-Standards einzeln anzuwenden.

Als ich gerade anfing, als Programmierer zu arbeiten, hörte ich einmal oft: „Bitte schreiben Sie eine Dokumentation für Ihr Programm.“ Ich habe alles ehrlich beschrieben, es meinem Chef gegeben, woraufhin die Sitzung mit der schwarzen Magie begann. Nach einer Weile rief mich der Chef an und fing an, unartikulierte Laute zu murmeln, den Ausdruck meines „besten“ Textes in seinen Händen zu zerknüllen und seine Augen zu huschen. Die allgemeine Bedeutung seines Muhens war, dass es sich als „falsch“, „falsch“ und „Schau dir an, was andere tun“ herausstellte. Da es unmöglich war, ihm eine andere Antwort zu entlocken, suchte ich bei „Andere“ nach Dokumentenbeispielen. In der Regel handelte es sich um fröhliche Kerle, deren Reden bedeuteten: „Hier sind Beispiele“, „im Allgemeinen laut GOST“ und „das alles braucht niemand“. So habe ich zum ersten Mal erfahren, dass ein Programmierer mit schrecklichen GOST-Standards in Berührung kommen kann.
Es ist erstaunlich, dass es unter vielen Dutzend meiner Kollegen, sehr intelligente Programmierer, niemanden gab, der GOSTs anders behandeln würde. Sogar die wenigen Leute, die sie kannten und anscheinend sogar wussten, wie man Dokumente erstellt, behandelten sie mit Verachtung und Förmlichkeit. In vielen Unternehmen kommt es immer wieder vor, dass selbst die Verantwortlichen für das Entwicklungsmanagement nicht verstehen, warum GOSTs benötigt werden und wie sie angewendet werden. Ja, es gab Unternehmen, die verstanden haben, wie sich die „Programmbeschreibung“ von der „Beschreibung der Bewerbung“ unterscheidet, aber es gab eine deutliche Minderheit von ihnen. Im Internet herrscht die Meinung vor, dass GOSTs für Programmierer ein offensichtliches Rudiment sind und nur dann benötigt werden, wenn sie sich ihnen „beugen“. Der vorläufige Entwurf wird „vergleichsweise“ betrachtet auf ehrliche Weise dem Kunden überschüssige Banknoten wegnehmen.“ Ich musste mich erst vor relativ kurzer Zeit damit befassen und es verstehen – im Zuge der Entwicklung eines auf die heimischen Besonderheiten zugeschnittenen Anforderungsmanagementsystems. Dokumentation, die natürlich „nach GOST“ erstellt werden muss.

Hier möchte ich mich nur auf ein Thema konzentrieren, mit dem sich ein Programmierer in inländischen Unternehmen, insbesondere in Forschungsinstituten, auseinandersetzen muss – die ESPD-Standards. Ich halte mich nicht für einen großen ESPD-Experten – es gibt Leute, die seit Jahrzehnten daran arbeiten und mich sicherlich korrigieren werden. Vielmehr versucht der Artikel, die Grundzüge einer „Roadmap“ für Einsteiger zu skizzieren.

Standards

Werfen wir einen kurzen Blick darauf, welche Standards es gibt (mit Schwerpunkt auf dem IT-Bereich).

International. Eine Besonderheit ist, dass es von einer internationalen Organisation übernommen wurde. Ein Beispiel für eine solche Organisation ist ISO (International Organization for Standardization). Ein Beispiel seiner Norm: ISO 2382-12:1988 (Peripheriegeräte). Gemeinsame Normen der ISO und der Internationalen Elektrotechnischen Kommission (IEC, auf Russisch – IEC) sind weit verbreitet: zum Beispiel ISO/IEC 12207:2008 ( Lebenszyklus VON);
regional. Eine Besonderheit - von der regionalen Normungskommission übernommen. Beispielsweise sind viele sowjetische GOSTs heute regionale Standards, weil angenommen vom zwischenstaatlichen Rat, dem einige ehemalige Sowjetrepubliken angehören. Dieser Rat verabschiedet auch neue Standards – und sie erhalten auch die GOST-Kennzeichnung. Beispiel: GOST 12.4.240-2013;
Standards öffentlicher Verbände; Zum Beispiel die gleiche IEC: IEC 60255;
nationale Standards. Für Russland ist „GOST R“ der Beginn solcher Standards. Es kann drei Arten geben:
1. exakte Kopien internationaler oder regionaler Dokumente. Sie sind nicht zu unterscheiden von „selbst verfasst“ (national, unabhängig verfasst);
2. Kopien internationaler oder regionaler Versionen mit Ergänzungen. Sie werden dadurch gekennzeichnet, dass zur Chiffre des inländischen Standards die zugrunde gelegte internationale Chiffre hinzugefügt wird. Zum Beispiel: GOST R ISO/IEC 12207;
3. eigentlich nationale Standards. Zum Beispiel GOST R 34.11-94.

Die Notationssysteme auf jeder Ebene und in jeder Organisation sind unterschiedlich; jeder Fall muss separat analysiert werden. Um schnell zu verstehen, „wessen“ Standard vor Ihren Augen liegt, können Sie einen Spickzettel verwenden.

GOST

Also: Standards sind international, zwischenstaatlich (regional) und national. GOST ist, wie wir herausgefunden haben, ein regionaler Standard. GOSTs haben meiner Meinung nach ein ziemlich verwirrendes Notationssystem. Es ist vollständig in GOST R 1.5-2004 dargelegt, ich werde das Minimum für die Navigation angeben. Zunächst muss zwischen der GOST-Bezeichnung und ihrer Klassifizierung unterschieden werden. Eine Bezeichnung ist, grob gesagt, eine eindeutige Kennung für einen Standard. Ein Klassifikationscode ist ein Hilfscode, der dabei hilft, einen Standard zu finden oder zu bestimmen, zu welchem Wissensbereich er gehört. Es kann viele Klassifikatoren geben, hauptsächlich werden zwei verwendet: KGS (Klassifikator staatlicher Standards) und sein Nachfolger OKS (allrussischer Klassifikator von Standards). Beispiel: „GOST R 50628-2000“ ist die Bezeichnung des Standards. Aus der Bezeichnung geht nur hervor, dass er im Jahr 2000 übernommen wurde. Es hat einen OKS-Code „33.100;35.160“: d.h. „33“ – Abschnitt „Telekommunikation, Audio, Video“, „100“ – Unterabschnitt „Elektromagnetische Verträglichkeit“. Es ist jedoch auch im 35.160-Klassifikatorzweig enthalten. „35“ – „ Informationstechnologie. Büromaschinen“, „160“ – „Mikroprozessorsysteme…“. Und laut KGS hat es den Code „E02“, was „E“ – „Elektronische Technologie, Funkelektronik und Kommunikation“, „0“ – „ Allgemeine Regeln und Standards für Elektronische Technologie, Funkelektronik und Kommunikation“ usw.

Wenn Sie die Bezeichnung des Standards kennen, können Sie auf dieser smarten Website beispielsweise dessen Codes für KGS und OKS abrufen.
Kehren wir also zu den GOST-Bezeichnungen zurück. Es gibt zwei Möglichkeiten:

Standard bezieht sich auf eine Reihe von Standards. In diesem Fall stehen nach dem Standardkategorieindex (z. B. GOST, GOST R oder GOST RV) ein Seriencode, ein Punkt und die Bezeichnung des Standards innerhalb der Serie. Die Regeln zur Benennung von Normen innerhalb einer Reihe werden durch die Regeln der Reihe festgelegt. Zum Beispiel: GOST RV 15.201-2000, GOST R 22.8.0-99, GOST 19.101-77;
Der Standard gehört nicht zu einer Reihe von Standards. Hinter dem Kategorieindex stehen dann lediglich die Seriennummer des Standards, ein Bindestrich und das Jahr der Einführung. Zum Beispiel GOST R 50628-2000.

Vereinfacht ausgedrückt ist die GOST-Bezeichnung also je nach Serie entweder einfach eine Seriennummer, ein Bindestrich, eine Jahreszahl oder eine Seriennummer, ein Punkt usw. In Wirklichkeit ist alles komplizierter (zum Beispiel gibt es so etwas wie GOST 11326.19-79, und es wird überhaupt nicht die 11326-Serie sein – aber Programmierer brauchen das sehr selten. Einzelheiten finden Sie in GOST R 1.5-2004).

ESPD

ESPD ist eine dieser GOST-Serien, Nummer 19. Das heißt. Alle ESPD-bezogenen Standards beginnen mit dem Präfix „19.“: zum Beispiel GOST 19.106-78. Steht für „Unified System of Program Documentation“. Es gibt noch weitere Serien:

GOST ESKD (einheitliches System der Konstruktionsdokumentation, Präfix „2.“);
GOST ESTD (einheitliches System der technischen Dokumentation, Präfix „3.“);
GOST R, System zur Entwicklung und Produktion von Produkten, Präfix „15.“;
GOST RV, Bewaffnung und militärische Ausrüstung. System zur Entwicklung und Einführung von Produkten in die Produktion, Präfix „15.“;
GOST, System der technischen Dokumentation für automatisierte Kontrollsysteme, Präfix „24.“;
GOST, eine Reihe von Standards für automatisierte Systeme, Präfix „34.“

Die ESPD enthält also eine Reihe von Standards, die bei der Entwicklung verwendet werden Software. Als nächstes wird für jeden Standard der ESPD dieser angegeben eine kurze Beschreibung von und Erklärung für nicht offensichtliche Fälle.

19.001-77. Allgemeine Bestimmungen

Beschreibt die Regeln für die Vergabe von Bezeichnungen an Normen der ESPD-Reihe. Im praktischen Leben nicht nötig.

19.102-80. Schemata von Algorithmen und Programmen. Ausführungsregeln.

Beschreibt die Regeln zum Konstruieren und Entwerfen von Algorithmen. Verwendet die Notation von 19.103. In meiner Praxis wurde es nur dann benötigt, wenn das Zertifizierungslabor formal darauf bestand, dass es das Algorithmusdiagramm war, das benötigt wurde. Aus meiner Sicht gehören klassische Flussdiagramme der Vergangenheit an und sind nur noch dann einigermaßen sinnvoll, wenn der Autor bei der Präsentation die Aufmerksamkeit des Lesers auf den Algorithmus lenken möchte.

19.003-80. Schemata von Algorithmen und Programmen. Konventionelle grafische Symbole

Es werden grafische Bezeichnungen akzeptabler Arten von Blockdiagrammelementen angegeben. Erforderlich, wenn Flussdiagramme verwendet werden.

19.004-80. Begriffe und Definitionen.

Dürftiges Glossar. Das Interessanteste ist, dass es formale Definitionen von Programm- und Betriebsdokumenten enthält.

19.005-85. P-Schemata von Algorithmen und Programmen

Fast eine vergessene Sprache. Einst waren P-Schemata in der Raketen- und Raumfahrtindustrie weit verbreitet und wurden zum De-facto-Standard für das Schreiben von Startkontrollprogrammen und die Simulation von Starts. Mittlerweile ist diese Sprache jedoch völlig vergessen. Bei meiner Arbeit bin ich noch nie auf P-Schemata gestoßen. Allerdings haben sie im Vergleich zu Blockdiagrammen spürbare Vorteile: Sie sind kompakt und eignen sich zur Visualisierung nichtlinearer Algorithmen (z. B. Klassen in C++) oder Datenstrukturen. Gleichzeitig gibt es im Internet praktisch keine Informationen darüber: Ich fand diese und diese Seite nützlich. Wenn ich jetzt ein Algorithmusdiagramm in die Softwaredokumentation einfügen müsste, würde ich auf jeden Fall P-Charts anstelle von Flussdiagrammen wählen.

19.101-77. Arten von Programmen und Programmdokumenten

Enthält eine Entsprechungstabelle zwischen einem Dokumenttyp und seinem Code sowie eine Unterteilung der Dokumenttypen in Betriebs- und Programmtypen. Das Konzept von Komplex und Komponente wird eingeführt. Es gibt nichts anderes Nützliches.

19.102-77. Entwicklungsstadien

Ein wichtiger und notwendiger Standard, der die Arten von Dokumenten beschreibt und Codes für die Arten von Programmdokumenten bereitstellt. Dieser Standard (zusammen mit 19.103-77) ist einer der Schlüssel zur „Entschlüsselung“ der Bezeichnungen von Dokumenten wie ABVG.10473-01 32 01-1.
Der Standard führt das Konzept eines Komplexes und einer Komponente ein (einige Unternehmen fügen einen dritten Typ hinzu – einen Bausatz, wenn wir reden überüber nicht zusammenhängende Programmelemente) wird eine Unterteilung vorgenommen: welche Dokumente betriebsbereit sind und welche nicht.
Mit Tabelle 4 sollten Sie vorsichtig sein. Sie zeigt, welches Dokument in welchem Entwicklungsstadium ausgeführt wird. In Standards zur Umsetzung von Konstruktions- und Entwicklungsarbeiten werden in der Regel die Entwicklungsstadien geregelt und dort auch angegeben, welche Unterlagen dem Kunden jeweils vorgelegt werden müssen.

19.102-77. Entwicklungsstadien

Soweit ich mich erinnere, wurde dieser Standard noch nie verwendet: Wer in welcher Phase was macht und worüber er berichtet, ist in den technischen Spezifikationen festgehalten oder es wird auf GOSTs verwiesen, wo dies klarer angegeben ist (z. B. GOST RV 15.203). ). Gleichzeitig enthält es für Anfänger einen recht prägnanten Überblick über die Arbeit an den Hauptstadien der Zwangsstörung.

19.103-77. Bezeichnungen von Programmen und Programmdokumenten

Es wird hauptsächlich benötigt, um die Symbole von Dokumenten lesen zu lernen, die dem oben genannten ähneln. Allerdings ist das Verständnis der Notation hilfreich, wenn Sie darüber hinausgehen müssen Standardarbeit: Denken Sie beispielsweise daran, dass Dokumente mit Codes nach 90 benutzerdefiniert sind, d. h. beliebig. In meiner Praxis haben wir Dokument 93 veröffentlicht, das wir „Programmdokumentationserklärung“ nannten, Dokument 96 – „Montageanweisungen“.
Der gebräuchliche Ausdruck „Ausführungsoption“ fehlt in der ESPD und wird durch „Revisionsnummer“ ersetzt. Das ist einerseits nicht ganz richtig: Die Revisionsnummer sollte die Entwicklung des Programms verfolgen: Zuerst erscheint die erste Ausgabe, dann, beispielsweise nach der Revision, die zweite. Aber in der Praxis, wenn Sie eine Softwareversion für mehrere freigeben müssen Betriebssysteme(plattformübergreifende Software) gibt es keine andere Wahl. Genauer gesagt gibt es das, aber es ist falsch: Weisen Sie der Version für jedes Betriebssystem eine eigene Bezeichnung zu - und legen Sie mehrere Festplatten mit Quellcodes (je nach Anzahl der Betriebssysteme) in das Archiv ein, entwickeln Sie sie (eigentlich kopieren Sie sie). gesamte Dokumentation usw.... Das heißt. reine dumme und verwirrende Aktivität. Die Lösung in Form der Zuweisung einer Versionsnummer zu jedem Betriebssystem ermöglicht es, einige Dokumente gemeinsam zu machen.
Das ESPD verwendet die Bezeichnung des Quellcodes des Programms und des Ergebnisses der Assemblierung als „Dokumente“, was viele Programmierer verwirrt. Das Dokument „Programmtext“ trägt gemäß 19.101-77 die Bezeichnung 12. Es wird weiterhin angenommen, dass der Quellcode mit 12 01 bezeichnet wird – also 01 (das erste) Dokument vom Typ 12 und Binärdateien – wie 12 02 – d.h. das zweite Dokument vom Typ 12. In einigen Fällen sind zusätzliche Tools erforderlich, um ein Programm zu erstellen – Compiler, Installer-Generatoren usw. Diese. Programme, die nicht im Lieferumfang enthalten sind, aber zur Montage benötigt werden. Eine Lösung könnte darin bestehen, sie als 12 03 zu bezeichnen – d. h. drittes Dokument vom Typ 12.

19.104-78. Grundlegende Inschriften

Beschreibt zwei Blätter des Dokuments – das Genehmigungsblatt (AL) und die Titelseite. Das Genehmigungsblatt in der ESPD enthält Unterschriften sowohl der Behörden, die das Dokument genehmigt haben, als auch der Entwickler, normativen Prüfer, Abnahmebeauftragten usw. Diese. Es enthält eine ganze Reihe sensibler Informationen für das Unternehmen. Daher geht der Standard davon aus, dass die LU beim Entwicklungsunternehmen verbleibt und nur auf besondere Anweisung hin versendet wird. Noch einmal: Die LU ist nicht Teil des Dokuments, sondern sozusagen ein separates Dokument und wird als separate Zeile in die Spezifikation aufgenommen.
Die zunächst verwirrende Kuriosität in der Trennung der LU vom Dokument selbst hat sehr gute Gründe:

Wie bereits erwähnt, möchte ein Unternehmen häufig keine Informationen über den Entwickler preisgeben. Durch die Trennung der LU und deren „Zusammendrücken“ ist dies möglich (anders als beim ESKD gibt es beim ESPD keinen Stempel auf den Dokumentenblättern; alle Informationen sind nur in der LU lokalisiert);
Eine Reihe von Unternehmen verwenden einen gemischten Dokumentenfluss: Originaldokumente werden darin gespeichert im elektronischen Format in den Archiven des Unternehmens und die darauf befindlichen Nummernschilder (mit Originalunterschriften) – in Papierform;

Was die Registrierung von LU angeht, verwenden Unternehmen häufig eine Mischung – einige der LU-Inschriften werden nach der ESPD erstellt, einige nach der ESKD und einige – auf ihre eigene Weise. Bevor Sie LU selbst erstellen, ist es daher am besten, nach einem Unternehmensstandard (STO) zu suchen oder sich ein Beispiel bei der lokalen Regulierungsbehörde zu holen.
Es sollte auch daran erinnert werden, dass die LU nicht nummeriert ist und die erste Seite die Titelseite ist und die erste Seite, auf der die Nummer platziert ist, neben der Titelseite liegt. Wenn jedoch mehr als eine LU vorhanden ist (dies geschieht, wenn nicht alle Signaturen auf das Blatt passen), werden die LUs separat nummeriert.

19.105-78. Allgemeine Anforderungen Dokumente zu programmieren

Die allgemeine Struktur des Dokuments wird unabhängig von der Art seiner Ausführung vorgestellt. Diese. Bereits 1978 wurde in der Norm festgelegt, dass es sich bei einem Dokument nicht unbedingt um ein Papierdokument handeln muss. Insbesondere wird der Begriff des Inhalts vollständig eingeführt elektronische Dokumente. Für die damals übliche Papierausführung wurde GOST 19.106-78 übernommen.
Derzeit muss man selten auf diesen Standard zurückgreifen: es sei denn, man vergisst die Reihenfolge der Hauptteile des Dokuments.

19.106-78. Allgemeine Anforderungen an gedruckte Programmdokumente

Der umfassendste Standard der ESPD, gleich nach der Beschreibung von R-Schemata. Es ist der wichtigste Arbeitsstandard bei der Erstellung der Dokumentation. Führt Regeln für die Formatierung von Text, Dokumentstrukturelementen, Bildern, Formeln usw. ein. Allerdings ist 19.106 im Gegensatz zum entsprechenden 2.106 aus dem ESKD deutlich weniger detailliert, was zu zahlreichen Unsicherheiten führt.
Erstens definiert der Standard den Zeilenabstand und den vertikalen Abstand zwischen Überschriften nicht wirklich. Er führt drei Regeln zur Bestimmung des Abstands ein: für maschinengeschriebenen Text, maschinell und typografisch.
Typoskript ist Text, der auf einer Schreibmaschine getippt wird. Die Verschiebung der nächsten Zeile relativ zur vorherigen erfolgte automatisch beim sogenannten „Wagenrücklauf“ – dem Übergang zum Drucken der nächsten Zeile, der durch Bewegen eines speziellen Hebels erzeugt wurde. Normalerweise konnte der Abstand manuell durch Drehen der Papiereinzugswelle eingestellt werden und verfügte über eine „Einstellung“, mit der Sie die Abstandsgröße festlegen konnten – einfach oder doppelt.
Der Maschinentyp ist höchstwahrscheinlich der gedruckte Text. Doch für ihn gibt es nur einen Hinweis darauf, dass das Ergebnis für die Mikroverfilmung geeignet sein muss. Dies ist ein impliziter Verweis auf 13.1.002-2003, der leider spezifiziert Zeilenabstand(und übrigens die Mindestschrifthöhe) nur für handschriftliche Dokumente (Ziffer 4.2.5).
Typografisch – in einer Druckerei getippter Text. In Anbetracht des Jahres, in dem der Standard verabschiedet wurde, handelt es sich höchstwahrscheinlich um dieses Jahr
[Buchdruck, bei dem der Zeilenabstand durch die verwendete Schrift bestimmt wurde. Ich bin kein Experte für Typografie und es gibt derzeit nur sehr wenige Informationen über Satzmethoden.
Welches Intervall am Ende zu verwenden ist, wird oft durch örtliche Vorschriften oder Tankstellen bestimmt. Typische Werte sind eineinhalb Zeilenabstand und Schriftgröße 14.
Die Art und Weise, wie ein Dokument strukturiert ist, wirft oft viele Fragen auf. 19.106 geht davon aus, dass das gesamte Dokument in Abschnitte, Unterabschnitte, Absätze und Unterabsätze unterteilt ist. Alle (mit Ausnahme der Abschnitte und Unterabschnitte) können einen Titel haben oder auch nicht. Dabei:

„Der Inhalt des Dokuments umfasst die Anzahl der Abschnitte, Unterabschnitte, Klauseln und Unterklauseln, die einen Titel haben“ (Klausel 2.1.4). Dies ist ein direkter Hinweis darauf, dass der Unterabschnitt möglicherweise einen Titel hat und in das Inhaltsverzeichnis aufgenommen wird.
„Es ist erlaubt, Text zwischen Abschnitts- und Unterabschnittsüberschriften, zwischen Unterabschnitts- und Absatzüberschriften zu platzieren.“ Es ist wichtig zu beachten, dass nicht nummerierter Text nur zwischen Überschriften und nur auf den beiden obersten Ebenen stehen darf.

Im Gegensatz zum ESKD verwendet das ESPD eine seltsame Art der Formatierung von Zeichnungen: Zuerst kommt der Name der Zeichnung, dann die Zeichnung selbst, dann der optionale „Text unter der Abbildung“ und dann in einer neuen Zeile „Abb.“ N".
Dieser Standard weist eine Reihe von „Lücken“ und Inkonsistenzen auf. Beispielsweise heißt es: „Abbildungen, sofern vorhanden.“ dieses Dokument mehr als eine, werden im gesamten Dokument mit arabischen Ziffern nummeriert. „Aber wenn es nur eine Abbildung gibt, dann ist sie nicht nummeriert, und wie kann man dann darauf verweisen? Das Gleiche gilt für Tische. Für Fußnoten gibt GOST nicht die Art ihrer Nummerierung an – innerhalb des gesamten Dokuments oder innerhalb der Seite.
Tische. Das Dokument selbst enthält einen Verweis auf GOST 1.5.68. Aus der ersten Folge lässt sich leicht schließen, dass es sich hierbei um einen Standard zur Entwicklung von Standards handelt. Was er damit zu tun hat, ist unklar. Im Sinne entspricht es bis auf geringfügige Ausnahmen den Regeln zur Tabellengestaltung im ESKD. Dieser Standard wurde abgeschafft und in mehreren Iterationen durch 1.5-2012 ersetzt, in dem die Tabellendesignregeln ... einfach verschwanden. Im Jahr 1,5-2002 waren sie da, aber schon im 1,5-2004 verschwanden sie. Im echten Leben erstellen wir Tabellen nach der ESKD.
Anwendungen. Die Norm gibt keine Auskunft darüber, ob Abbildungen, Formeln und Tabellen aus den Anhängen in die Gesamtliste aufgenommen werden. Ebenso wird nicht gesagt, ob das Inhaltsverzeichnis den Aufbau der Anmeldung offenlegen muss, wenn es eigene Abschnitte, Absätze usw. enthält. In unserer Praxis geben wir das Innere von Bewerbungen nicht preis.
Abschließend sollte noch etwas zur Einrückung gesagt werden. Ein Absatzeinzug von 5 Zeichen ist üblich für:

rote Linie;
Einrückung eines Dokumentstrukturelements nach einem Abschnitt (Unterabschnitt, Klausel, Unterabschnitt);
Aufzählungselement.

In den folgenden Abschnitten möchte ich zum Ende der Liste der ESPD-Standards kommen.

Computerprogramme werden gemäß den Anforderungen des Unified System of Program Documentation (USPD) erstellt. ESPD ist eine Reihe von GOSTs, die die Regeln für das Design, den Inhalt und die Struktur von Programmdokumenten festlegen.
Diese Anleitung enthält Auszüge aus der ESPD. Vollständige Informationen erhalten Sie direkt bei GOSTs.

Kurzer Programmdesign-Algorithmus

In der Abbildung sind kurz der Programmentwurfsalgorithmus und die Arten von Programmdokumenten dargestellt. Der Registrierungsprozess wird im Folgenden näher beschrieben.

Erstellung eines Programmdokuments

Programmdokument – ein Dokument, das Informationen enthält, die für die Entwicklung, Produktion, Wartung und den Betrieb von Programmen erforderlich sind.

Jedes einzelne Programmdokument wird in Übereinstimmung mit (allen ESPD-Dokumenten gemeinsamen) Anforderungen von GOST 19.101-77, GOST 19.103-77, GOST 19.104-78, GOST 19.105-78, GOST 19.106-78, GOST 19.604-78 erstellt ( mehr detaillierte Beschreibung GOST-Daten folgen unten) und GOST für ein bestimmtes Programmdokument.

Allgemeine Anforderungen an Programmdokumente. GOST 19.105 - 78

Anforderungen an gedruckte Programmunterlagen. GOST 19.106 - 78

GOST 19.106-78 legt die Regeln für die Ausführung von Programmdokumenten für die gedruckte Ausführungsmethode fest.

Es ist wichtig zu beachten, dass dieses GOST nicht für das Programmdokument „Programmtext“ gilt.

Materialien des Programmdokuments muss in der folgenden Reihenfolge vorliegen:

Titelteil:
- Genehmigungsblatt (nicht in der Gesamtzahl der Blätter des Dokuments enthalten);
- Titelseite (erste Seite des Dokuments);
Informationsteil:
- Anmerkung;
- Inhaltsverzeichnis;
Hauptteil:
- Text des Dokuments (mit Bildern, Tabellen etc.);
- Anwendungen;
- Begriffsverzeichnis, Abkürzungsverzeichnis, Abbildungsverzeichnis, Tabellenverzeichnis, Sachverzeichnis, Verzeichnis der Referenzdokumente;
- Protokollierungsteil ändern:
- Änderungsregistrierungsblatt.

Die Anmerkung gibt die Ausgabe des Programms an und umreißt kurz Zweck und Inhalt des Dokuments. Besteht das Dokument aus mehreren Teilen, wird in der Anmerkung die Gesamtzahl der Teile angegeben. Der Inhalt des Dokuments wird auf einer separaten (nummerierten) Seite(n) nach der Anmerkung platziert, mit der Überschrift „INHALT“ versehen, nicht als Abschnitt nummeriert und in die Gesamtseitenzahl des Dokuments einbezogen.

Textformatierung:

Das Programmdokument wird in zwei Abständen auf einer Seite des Blattes ausgeführt; in einem oder anderthalb Abständen erlaubt.
Die Zusammenfassung wird auf einer separaten (nummerierten) Seite mit der Überschrift „ABSTRACT“ platziert und nicht als Abschnitt nummeriert.
Abschnittsüberschriften werden in Großbuchstaben geschrieben und symmetrisch zum rechten und linken Textrand platziert.
Unterabschnittsüberschriften werden aus dem Absatz in Kleinbuchstaben geschrieben (mit Ausnahme des ersten Großbuchstabens).
Die Silbentrennung von Wörtern in Überschriften ist nicht zulässig. Am Ende des Titels steht kein Punkt.
Der Abstand zwischen der Überschrift und dem folgenden Text sowie zwischen Abschnitts- und Unterabschnittsüberschriften sollte gleich sein:
- beim Ausführen eines Dokuments per Schreibmaschine - zwei Intervalle.
Bei Abschnitten und Unterabschnitten, deren Text auf derselben Seite wie der Text des vorherigen Abschnitts geschrieben ist, sollte der Abstand zwischen der letzten Textzeile und der nachfolgenden Überschrift gleich sein:
- beim Ausführen eines Dokuments mit einer maschinengeschriebenen Methode - drei maschinengeschriebene Intervalle.
Abschnitte, Unterabschnitte, Absätze und Unterabsätze sollten in arabischen Ziffern mit einem Punkt nummeriert werden.
Innerhalb eines Abschnitts muss eine fortlaufende Nummerierung aller in diesem Abschnitt enthaltenen Unterabschnitte, Absätze und Unterabsätze erfolgen.
Die Nummerierung der Unterabschnitte umfasst die Abschnittsnummer und die laufende Nummer des in diesem Abschnitt enthaltenen Unterabschnitts, getrennt durch einen Punkt (2.1; 3.1 usw.).
Wenn es Abschnitte und Unterabschnitte gibt, wird die laufende Nummer des Abschnitts und Unterabschnitts (3.1.1, 3.1.1.1 usw.) nach dem Punkt zur Unterabschnittsnummer hinzugefügt.
Der Text des Dokuments sollte kurz und klar sein und die Möglichkeit einer Fehlinterpretation ausschließen.
Begriffe und Definitionen müssen einheitlich sein und den etablierten Standards entsprechen, und in deren Fehlen sie allgemein in der wissenschaftlichen und technischen Literatur akzeptiert werden und in der Liste der Begriffe aufgeführt sein.
Notwendige Erläuterungen zum Text des Dokuments können in Fußnoten erfolgen.
Eine Fußnote wird durch eine Zahl mit Klammer auf Höhe des oberen Schriftrandes gekennzeichnet, zum Beispiel: „Druckgerät2)…“ oder „Papier5)“.
Bezieht sich eine Fußnote auf ein einzelnes Wort, steht das Fußnotenzeichen direkt neben diesem Wort, bezieht es sich jedoch auf einen Satz als Ganzes, dann am Ende des Satzes. Der Fußnotentext wird am Ende der Seite platziert und durch eine 3 cm lange Linie am linken Seitenrand vom Haupttext getrennt.
Abbildungen werden im gesamten Dokument mit arabischen Ziffern nummeriert, wenn in einem bestimmten Dokument mehr als eine davon vorhanden ist.
Wenn es in einem Dokument mehrere Formeln gibt, werden diese in arabischen Ziffern nummeriert; die Nummer wird auf der Formelebene auf der rechten Seite der Seite in Klammern gesetzt.
Die Bedeutung der in der Formel enthaltenen Symbole und Zahlenkoeffizienten muss direkt unterhalb der Formel angegeben werden. Die Bedeutung jedes Zeichens wird in der Reihenfolge, in der sie in der Formel angegeben sind, in einer neuen Zeile gedruckt. Die erste Zeile des Transkripts sollte mit dem Wort „wo“ beginnen, ohne einen Doppelpunkt dahinter.
In Programmdokumenten sind Verweise auf Normen (außer Unternehmensstandards), technische Spezifikationen und andere Dokumente (z. B. Dokumente staatlicher Aufsichtsbehörden, Regeln und Vorschriften des Staatlichen Baukomitees der UdSSR) zulässig. Bei Verweisen auf Normen und technische Spezifikationen wird deren Bezeichnung angegeben.
Es sollte auf das Dokument als Ganzes oder auf seine Abschnitte Bezug genommen werden (unter Angabe der Bezeichnung und des Namens des Dokuments, der Nummer und des Namens des Abschnitts oder der Anlage). Bei wiederholten Verweisen auf einen Abschnitt oder eine Anwendung wird nur die Nummer angegeben.
Hinweise zum Text und zu den Tabellen geben lediglich Referenz- und Erläuterungsdaten an.
Eine Note ist nicht nummeriert. Fügen Sie nach dem Wort „Hinweis“ einen Punkt ein.
Mehrere Notizen sollten der Reihe nach mit arabischen Ziffern und einem Punkt nummeriert werden. Fügen Sie nach dem Wort „Hinweis“ einen Doppelpunkt ein.
Abkürzungen von Wörtern im Text und Beschriftungen unter Abbildungen sind nicht zulässig.
Bildmaterial, Tabellen oder Begleittexte können in Form von Anhängen präsentiert werden.
Jede Bewerbung muss mit beginnen neue Seite Geben Sie in der oberen rechten Ecke das Wort „ANWENDUNG“ an und haben Sie eine thematische Überschrift, die symmetrisch zum Text in Großbuchstaben geschrieben ist.

GOST enthält ein Musterblatt, das die Felder, Stellen für die Seitennummerierung und den Code angibt.

GOST 19.101-77

Gruppe T55

ZWISCHENSTAATLICHER STANDARD

Einheitliches System der Programmdokumentation

ARTEN VON PROGRAMMEN UND PROGRAMMDOKUMENTEN

Einheitliches System zur Programmdokumentation. Arten von Programmen und Programmdokumenten

MKS 35.080

Datum der Einführung: 01.01.1980

Mit Beschluss des Staatlichen Normenkomitees des Ministerrates der UdSSR vom 20. Mai 1977 N 1268 wurde der Einführungstermin auf den 01.01.80 festgelegt

AUSGABE (Januar 2010) mit Änderung Nr. 1, genehmigt im Juni 1981 (IUS 9-81).

Diese Norm legt die Arten von Programmen und Programmdokumenten für Computer, Komplexe und Systeme fest, unabhängig von ihrem Zweck und Umfang.

Der Standard entspricht vollständig ST SEV 1626-79.

(Geänderte Ausgabe, Änderung Nr. 1).

1. ARTEN VON PROGRAMMEN

1.1. Das Programm (gemäß GOST 19781-90) kann unabhängig und (oder) als Teil anderer Programme identifiziert und verwendet werden.

1.2. Die Programme sind in die in Tabelle 1 aufgeführten Typen unterteilt.

Tabelle 1


Programmtyp	Definition
Komponente	Ein als Ganzes betrachtetes Programm, das eine vollständige Funktion ausführt und unabhängig oder als Teil eines Komplexes verwendet wird
Komplex	Ein Programm, das aus zwei oder mehr Komponenten und (oder) Komplexen besteht, die miteinander verbundene Funktionen erfüllen und unabhängig oder als Teil eines anderen Komplexes verwendet werden

1.3. Die für das Programm entwickelte Dokumentation kann für die Implementierung und Übertragung des Programms auf Speichermedien sowie für die Herstellung eines Softwareprodukts verwendet werden.

1.2, 1.3. (Geänderte Ausgabe, Änderung Nr. 1).

2. ARTEN VON PROGRAMMDOKUMENTEN

2.1. Softwaredokumente umfassen Dokumente, die Informationen enthalten, die für die Entwicklung, Produktion, Wartung und den Betrieb von Programmen erforderlich sind.

2.2. Die Arten von Programmdokumenten und deren Inhalte sind in Tabelle 2 aufgeführt.

Tabelle 2


Art des Programmdokuments
Spezifikation	Zusammensetzung des Programms und seiner Dokumentation
	Liste der Unternehmen, die Originaldokumente des Programms aufbewahren
Programmtext	Aufnahme der Sendung mit den nötigen Kommentaren
Programm Beschreibung	Informationen zum logischen Aufbau und zur Funktionsweise des Programms
	Anforderungen, die beim Testen des Programms überprüft werden müssen, sowie die Vorgehensweise und Methoden zu deren Kontrolle
Technische Aufgabe	Zweck und Umfang des Programms, technische, Durchführbarkeit und besondere Anforderungen an das Programm, notwendige Entwicklungsschritte und -bedingungen, Arten von Tests
Erläuterungen	Algorithmusdiagramm, allgemeine Beschreibung des Algorithmus und (oder) der Funktionsweise des Programms sowie Begründung der getroffenen technischen und technisch-wirtschaftlichen Entscheidungen
Betriebsdokumente	Informationen zur Sicherstellung der Funktionsfähigkeit und des Betriebs des Programms

2.3. Die Arten von Betriebsdokumenten und deren Inhalt sind in Tabelle 3 aufgeführt.

Tisch 3


Art des Betriebsdokuments
	Liste der operativen Dokumente für das Programm
Bilden	Hauptmerkmale des Programms, Vollständigkeit und Informationen zur Funktionsweise des Programms
Beschreibung der Anwendung	Informationen über den Zweck des Programms, Anwendungsbereich, verwendete Methoden, Klasse der zu lösenden Probleme, Einschränkungen bei der Nutzung, Mindestkonfiguration der Hardware
	Informationen zur Überprüfung, Sicherstellung der Funktionsfähigkeit und Anpassung des Programms an die Bedingungen einer bestimmten Anwendung
Programmierhandbuch	Informationen zur Nutzung des Programms
Benutzerhandbuch	Informationen zur Sicherstellung des Verfahrens zur Kommunikation zwischen dem Bediener und dem Computersystem während der Programmausführung
Sprachbeschreibung	Beschreibung der Syntax und Semantik der Sprache
	Informationen zur Verwendung von Test- und Diagnoseprogramme bei der Wartung technischer Geräte

2.4. Abhängig von der Implementierungsmethode und der Art der Anwendung werden Programmdokumente in Original, Duplikat und Kopie (GOST 2.102-68) unterteilt, die für die Entwicklung, Wartung und den Betrieb des Programms bestimmt sind.

2.5. Die Arten von Programmdokumenten, die in verschiedenen Phasen entwickelt wurden, und ihre Codes sind in Tabelle 4 aufgeführt.

Tabelle 4


Code Art des Dokuments	Art des Dokuments	Entwicklungsstadien
		Vorläufiger Entwurf	Technisches Projekt	Arbeitsentwurf
				Komponente	Komplex
	Spezifikation
	Liste der ursprünglichen Inhaber
	Programmtext
	Programm Beschreibung
	Liste der Betriebsdokumente
	Bilden
	Beschreibung der Anwendung
	Handbuch für Systemprogrammierer
	Programmierhandbuch
	Benutzerhandbuch
	Sprachbeschreibung
	Wartungshandbuch
	Testprogramm und Methodik
	Erläuterungen
	Sonstige Unterlagen

Legende:

- Das Dokument ist obligatorisch;

- Das Dokument ist für Komponenten mit unabhängiger Verwendung obligatorisch.

- Die Notwendigkeit der Erstellung eines Dokuments wird in der Phase der Entwicklung und Genehmigung der technischen Spezifikationen festgestellt;

- - Das Dokument wird nicht erstellt.

2,2-2,5. (Geänderte Ausgabe, Änderung Nr. 1).

2.6. Es ist erlaubt, bestimmte Arten von Betriebsdokumenten zu kombinieren (mit Ausnahme der Liste der Betriebsdokumente und des Formulars). Die Notwendigkeit, diese Dokumente zusammenzuführen, ist in den technischen Spezifikationen angegeben. Dem zusammengeführten Dokument wird der Name und die Bezeichnung eines der zusammengeführten Dokumente zugewiesen.

In zusammengeführten Dokumenten müssen die Informationen angegeben werden, die in jedem zusammenzuführenden Dokument enthalten sein müssen.

2.7. In der Phase der Entwicklung und Genehmigung der technischen Spezifikationen besteht die Notwendigkeit der Erstellung technische Spezifikationen, die Anforderungen an die Erstellung, Steuerung und Abnahme des Programms enthält.

In der Phase „Detailed Design“ werden technische Spezifikationen erarbeitet.

2.8. Die Notwendigkeit der Erstellung technischer Spezifikationen für Komponenten, die nicht zur eigenständigen Verwendung bestimmt sind, und für Komplexe, die in andere Komplexe eingebunden sind, wird in Absprache mit dem Kunden festgelegt.

(Zusätzlich eingeführt, Änderung Nr. 1).

Elektronischer Dokumententext
erstellt von Kodeks JSC und überprüft gegen:
offizielle Veröffentlichung
Einheitliches Softwaresystem
Dokumentation: Sa. GOST. -
M.: Standartinform, 2010

G O S U D A R S T V E N N Y S T A N D A R T S O Y W A S S R

Einheitliches System der Programmdokumentation	GOST 19.101-77(ST SEV 1626-79)

ARTEN VON PROGRAMMEN UND PROGRAMMDOKUMENTEN
Vereinigtes System zur Programmdokumentation. Arten von Programmen und Programmdokumenten

Datum der Einführung ab 01.01.80

Diese Norm legt die Arten von Programmen und Programmdokumenten für Computer, Komplexe und Systeme fest, unabhängig von ihrem Zweck und Umfang.

Der Standard entspricht vollständig ST SEV 1626-79.

1. ARTEN VON PROGRAMMEN

1.1. Das Programm (gemäß GOST 19781-90) kann unabhängig und (oder) als Teil anderer Programme identifiziert und verwendet werden.

1.2. Die Programme sind in die in der Tabelle aufgeführten Typen unterteilt. 1

Tabelle 1

1.2,1.3.

2. ARTEN VON PROGRAMMDOKUMENTEN

2.1. Softwaredokumente umfassen Dokumente, die Informationen enthalten, die für die Entwicklung, Produktion, Wartung und den Betrieb von Programmen erforderlich sind.

2.2. Die Arten von Programmdokumenten und deren Inhalte sind in der Tabelle aufgeführt. 2.

Tabelle 2

Art des Programmdokuments	Inhalt des Richtliniendokuments
Spezifikation	Zusammensetzung des Programms und seiner Dokumentation
	Liste der Unternehmen, die Originaldokumente des Programms aufbewahren
Programmtext	Aufnahme der Sendung mit den nötigen Kommentaren
Programm Beschreibung	Informationen zum logischen Aufbau und zur Funktionsweise des Programms
	Anforderungen, die beim Testen des Programms überprüft werden müssen, sowie die Vorgehensweise und Methoden zu deren Kontrolle
Technische Aufgabe	Zweck und Umfang des Programms, technische, Durchführbarkeit und besondere Anforderungen an das Programm, notwendige Entwicklungsschritte und -bedingungen, Arten von Tests
Erläuterungen	Algorithmusdiagramm, allgemeine Beschreibung des Algorithmus und (oder) der Funktionsweise des Programms sowie Begründung der getroffenen technischen und technisch-wirtschaftlichen Entscheidungen
Betriebsdokumente	Informationen zur Sicherstellung der Funktionsfähigkeit und des Betriebs des Programms

(Geänderte Ausgabe, Änderung Nr. 1).

2.3. Die Arten von Betriebsdokumenten und deren Inhalt sind in Tabelle 3 aufgeführt.

Tisch 3

Art des Betriebsdokuments	Inhalt des Betriebsdokuments
	Liste der operativen Dokumente für das Programm
Bilden	Hauptmerkmale des Programms, Vollständigkeit und Informationen zur Funktionsweise des Programms
Beschreibung der Anwendung	Informationen über den Zweck des Programms, Anwendungsbereich, verwendete Methoden, Klasse der zu lösenden Probleme, Einschränkungen bei der Nutzung, Mindestkonfiguration der Hardware
	Informationen zur Überprüfung, Sicherstellung der Funktionsfähigkeit und Anpassung des Programms an die Bedingungen einer bestimmten Anwendung
Programmierhandbuch	Informationen zur Nutzung des Programms
Benutzerhandbuch	Informationen zur Sicherstellung des Verfahrens zur Kommunikation zwischen dem Bediener und dem Computersystem während der Programmausführung
Sprachbeschreibung	Beschreibung der Syntax und Semantik der Sprache
	Informationen zum Einsatz von Test- und Diagnoseprogrammen bei der Wartung technischer Geräte

(Geänderte Ausgabe, Änderung Nr. 1).

2.5. Die in verschiedenen Phasen entwickelten Arten von Programmdokumenten und ihre Codes sind in der Klicktabelle aufgeführt. 4.

Tabelle 4

Dokumenttypcode	Art des Dokuments	Entwicklungsstadien
		Vorläufiger Entwurf	Technisches Projekt	Arbeitsentwurf
		Vorläufiger Entwurf	Technisches Projekt	Komponente	Komplex
-	Spezifikation	-	-
05	Liste der ursprünglichen Inhaber	-	-	-
12	Programmtext	-	-
13	Programm Beschreibung	-	-
20	Liste der Betriebsdokumente	-	-
30	Bilden	-	-
31	Beschreibung der Anwendung	-	-
32	Handbuch für Systemprogrammierer	-	-
33	Programmierhandbuch	-	-
34	Benutzerhandbuch	-	-
35	Sprachbeschreibung	-	-
46	Wartungshandbuch	-	-
51	Testprogramm und Methodik	-	-
81	Erläuterungen			-	-
90-99	Sonstige Unterlagen

Legende:
- Das Dokument ist obligatorisch;
- Das Dokument ist für Komponenten mit unabhängiger Verwendung obligatorisch.
- Die Notwendigkeit der Erstellung eines Dokuments wird in der Phase der Entwicklung und Genehmigung der technischen Spezifikationen festgestellt;
- - Das Dokument wird nicht erstellt.

2.2-2.5. (Geänderte Ausgabe, Änderung Nr. 1).

In zusammengeführten Dokumenten müssen die Informationen angegeben werden, die in jedem zusammenzuführenden Dokument enthalten sein müssen.

2.7. In der Phase der Entwicklung und Genehmigung der technischen Spezifikationen wird die Notwendigkeit festgestellt, technische Spezifikationen zu erstellen, die Anforderungen an die Produktion, Steuerung und Abnahme des Programms enthalten.

In der Phase „Detailed Design“ werden technische Spezifikationen erarbeitet.

(Zusätzlich eingeführt, Änderung Nr. 1).

Neuauflage (November 1987) mit Änderung Nr. 1, genehmigt im Juni 1981 (IUS 9-81)