ESPD (プログラム文書の統一システム)。 プログラム文書の統一システム (USPD) プログラム文書の統一システムの新しい州標準
私がプログラマーとして働き始めたばかりの頃、「プログラムのドキュメントを書いてください」とよく言われました。 私はすべてを正直に説明し、上司に渡し、その後黒魔術のセッションが始まりました。 しばらくして、上司が私に電話をかけてきて、歯切れの悪い音をブツブツ言い始め、私の「最高の」テキストのプリントアウトを手の中でくしゃくしゃにして目を丸くしました。 彼の暴言の一般的な意味は、それが「間違っている」、「間違っている」、そして「他の人がやっていることを見てください」であることが判明したということでした。 彼からそれ以外の答えを引き出すことは不可能だったので、私は文書の例として「その他」に行きました。 原則として、これらは陽気な人々であり、そのスピーチの意味は、「ここに例があります」、「一般的に、GOSTによると」、「これすべてを必要とする人はいません」ということでした。 このようにして、プログラマーは恐ろしい GOST 標準に遭遇する可能性があることを初めて知りました。
驚くべきことに、非常に知的なプログラマである私の何十人もの同僚の中に、GOST を特別に扱う人が一人もいなかったことです。 彼らを知っており、文書の作成方法さえ知っているように見えた少数の人々でさえ、彼らを軽蔑し形式的に扱った。 開発管理の責任者ですら、GOST がなぜ必要なのか、どのように適用されるのかを理解していない状況は、多くの企業で常に発生しています。 はい、「プログラムの説明」と「申請の説明」がどのように異なるかを理解している企業もありましたが、明らかに少数派でした。 インターネット上では、プログラマにとって GOST は明らかな初歩であり、GOST に「従う」場合にのみ必要である、という考え方が主流です。 この草案のデザインは「顧客から余分な紙幣を取り除く比較的公平な方法」とみなされている。 私がこれを深く掘り下げて理解する必要があったのは比較的最近のことで、国内の特性に合わせた要件管理システムを開発する過程でした。 もちろん、ドキュメントは「GOSTに従って」作成する必要があります。
ここでは、国内企業、特に研究機関のプログラマが対処しなければならない 1 つのトピック、つまり一連の ESPD 標準に焦点を当てたいと思います。 私は自分自身を ESPD の優れた専門家だとは思っていません。ESPD に何十年も取り組んでいる人たちがいて、間違いなく私を正してくれるでしょう。 この記事はむしろ、物事を始めようとしている人向けの「ロードマップ」の概要を概説することを目的としています。
規格
どのような規格があるのか簡単に見てみましょう（IT分野を中心に）。- 国際的。 国際機関にも採用されているのが特徴です。 このような組織の例としては、ISO (国際標準化機構) があります。 その規格の例: ISO 2382-12:1988 (周辺機器)。 ISO と国際電気標準会議 (IEC、ロシア語 - IEC) の共同規格は広く普及しています。たとえば、ISO/IEC 12207:2008 (ソフトウェア ライフ サイクル)。
- 地域的な。 特徴的な機能 - 標準化のための地域委員会によって採用されました。 たとえば、多くのソビエト GOST は現在地域標準となっています。 一部の旧ソ連諸国を含む国家間評議会で採択された。 この評議会は新しい基準も採用しており、GOST の指定も受けています。 例: GOST 12.4.240-2013;
- 公的団体の基準。 たとえば、同じ IEC: IEC 60255;
- 国家基準。 ロシアにとって、そのような規格の始まりは「GOST R」です。 次の 3 つのタイプが考えられます。
- 国際または地域のコピーの正確なコピー。 それらは「自作」（全国的、独立して書かれたもの）と区別できないように指定されています。
- 追加された国際版または地域版のコピー。 国内標準の暗号に、それをベースにした国際暗号を加えて表示します。 例: GOST R ISO/IEC 12207;
- 実は国家基準。 たとえば、GOST R 34.11-94。
各レベルおよび各組織の表記システムは異なります。それぞれのケースを個別に分析する必要があります。 目の前にある「誰の」基準をすぐに理解するには、カンニングペーパーを使用できます。
ゴスト
つまり、標準は国際、州間 (地域)、および国内です。 GOST は地域の標準であることがわかりました。 私の意見では、GOST の表記システムはかなり混乱しています。 GOST R 1.5-2004 に完全に規定されているので、それをナビゲートするための最低限の情報を示します。 まず、GOST 指定とその分類を区別する必要があります。 名称は、大まかに言えば、規格の一意の識別子です。 分類子コードは、標準を見つけたり、それがどの知識領域に属するかを判断したりするのに役立つ補助コードです。 多くの分類子が存在しますが、主に 2 つが使用されます。KGS (国家標準分類子) とその後継の OKS (全ロシア標準分類子) です。 例: 「GOST R 50628-2000」は規格の名称です。この名称から、それが 2000 年に採用されたことが明らかです。 OKS コード「33.100;35.160」があります。つまり、 「33」 - セクション「電気通信、オーディオ、ビデオ」、「100」 - サブセクション「電磁両立性」。 ただし、35.160 分類子ブランチにも含まれています。 「35」 - 「情報技術。 オフィス マシン」、「160」 - 「マイクロプロセッサ システム...」。 そしてKGSによれば、コードは「E02」で、「E」-「電子技術、無線電子機器および通信」、「0」-「電子技術、無線電子機器および通信に関する一般規則および規制」などを意味します。標準の指定がわかっている場合は、たとえば、このスマート Web サイトで KGS と OKS のコードを取得できます。
それでは、GOST の指定に戻りましょう。 次の 2 つのオプションがあります。
- 標準とは一連の標準を指します。 この場合、標準カテゴリのインデックス (GOST、GOST R、または GOST RV など) の後に、シリーズ コード、ドット、およびシリーズ内の標準の指定が続きます。 シリーズ内で規格を指定するためのルールは、シリーズのルールによって確立されます。 例: GOST RV 15.201-2000、GOST R 22.8.0-99、GOST 19.101-77。
- この規格は一連の規格に属しません。 カテゴリ インデックスの後には、規格のシリアル番号、ダッシュ、および採用年が表示されます。 たとえば、GOST R 50628-2000。
ESPD
ESPD は、これらの GOST シリーズの 1 つ、番号 19 です。 ESPD に関連するすべての規格は、接頭辞「19.」で始まります。たとえば、GOST 19.106-78 です。 「Unified System of Program Documentation」の略です。 他にも次のシリーズがあります。- GOST ESKD (設計文書の統一システム、接頭辞「2.」);
- GOST ESTD (技術文書の統一システム、接頭辞「3.」);
- GOST R、製品の開発および生産のためのシステム、接頭辞「15.」;
- GOST RV、兵器および軍事機器。 製品を開発して実稼働環境に投入するためのシステム。接頭辞「15.」。
- GOST、自動制御システムの技術文書システム、接頭辞「24.」;
- GOST、自動化システムの標準セット、接頭辞「34.」。
19.001-77。 一般規定
ESPD シリーズの規格に指定を割り当てるためのルールについて説明します。 実生活では必要ありません。19.102-80。 アルゴリズムとプログラムのスキーム。 実行ルール。
アルゴリズムを構築および設計するためのルールについて説明します。 19.103からの表記を使用しています。 私の実務では、それが必要になったのは、認証機関が正式な根拠として、必要なのはアルゴリズム図であると主張したときだけでした。 私の観点からすると、古典的なフローチャートは過去のものであり、多かれ少なかれそれが適切であり続ける唯一の場所は、プレゼンテーションの際に著者が読者の注意をアルゴリズムに集中させたい場合です。19.003-80。 アルゴリズムとプログラムのスキーム。 従来の図記号
受け入れ可能なタイプのブロック図要素のグラフィック指定が示されています。 フローチャートを使用する場合は必須です。19.004-80。 用語と定義。
貧弱な用語集。 最も興味深いのは、プログラムと運用文書の正式な定義が含まれていることです。19.005-85。 アルゴリズムとプログラムの P スキーム
ほとんど忘れ去られた言語。 かつて、P スキームはロケットや宇宙産業で広く使用され、打ち上げ制御プログラムの作成や打ち上げのシミュレーションの事実上の標準となりました。 しかし、今ではこの言語は完全に忘れ去られています。 私の仕事では、P スキームに遭遇したことはありません。 ただし、ブロック図と比較すると、コンパクトで非線形アルゴリズム (C++ のクラスなど) やデータ構造を視覚化するのに適しているという顕著な利点があります。 同時に、インターネット上にはそれらに関する情報がほとんどありません。これとこのサイトが役に立ちました。 いずれにせよ、ソフトウェアのドキュメントにアルゴリズム図を挿入する必要がある場合、私はフローチャートではなく P チャートを選択するでしょう。19.101-77。 プログラムの種類とプログラムドキュメント
文書タイプとそのコードの対応表と、文書タイプを操作とプログラムに分類した表が含まれています。 複合体とコンポーネントの概念が導入されます。 これ以上便利なものはありません。19.102-77。 開発段階
ドキュメントの種類を説明し、プログラム ドキュメントの種類に応じたコードを提供する重要かつ必要な標準。 この規格 (19.103-77 と合わせて) は、ABVG.10473-01 32 01-1 のような文書の指定を「解明」するための鍵の 1 つです。この標準では、複合体とコンポーネントの概念が導入されており (多くの企業は、無関係なソフトウェア要素に関しては、3 番目のタイプであるセットを追加しています)、どの文書が機能し、どの文書が機能しないのかという区分が与えられています。
表 4 に注意してください。これは、開発のどの段階でどのドキュメントが実行されているかを示しています。 開発の段階は通常、設計および開発作業の実施に関する標準で規定されており、各段階で顧客にどの文書を提示する必要があるかもそこに示されています。
19.102-77。 開発段階
私の記憶では、この標準は一度も使用されたことがありません。誰がどの段階で何を行い、何を報告するかは技術仕様に記載されるか、GOST への参照が行われます。GOST にはこれがより明確に記載されています (たとえば、GOST RV 15.203)。 ）。 同時に、初心者向けに、OCD の主要な段階に関する作業のかなり簡潔な概要が含まれています。19.103-77。 プログラムおよびプログラム文書の指定
これは主に、上記のような文書の記号を読むことを学ぶために必要です。 ただし、表記体系を理解することは、標準的な作業を超えた作業を行う必要がある場合に役立ちます。たとえば、90 以降のコードを持つ文書はユーザー定義であることを覚えておいてください。 どれでも。 私の実務では、「プログラム文書声明」と呼ばれる文書93、文書96「アセンブリ手順」をリリースしました。ESPD には一般的な語句「実行オプション」が存在せず、「リビジョン番号」に置き換えられています。 一方では、これは完全に正しいわけではありません。リビジョン番号はプログラムの進化を追跡することを目的としており、最初に初版がリリースされ、次に、たとえば改訂後に第 2 版がリリースされます。 しかし実際には、複数のオペレーティング システム用のソフトウェア バージョン (クロスプラットフォーム ソフトウェア) をリリースする必要がある場合、他に選択肢はありません。 より正確に言えば、それはありますが、それは間違いです。各オペレーティング システムのバージョンに独自の指定を割り当て、（オペレーティング システムの数に応じて）ソース コードを含む複数のディスクをアーカイブに置き、そのファイルを開発（実際にはコピー）します。ドキュメント一式など....つまり。 純粋に愚かで混乱を招く活動。 各オペレーティング システムにバージョン番号を割り当てるという形式のソリューションにより、一部のドキュメントを共通にすることが可能になります。
ESPD では、プログラムのソース コードとアセンブリの結果を「ドキュメント」として指定していますが、これが多くのプログラマーを混乱させています。 19.101-77 によれば、文書「プログラムテキスト」には 12 という指定があります。さらに、ソースコードが 12 01 として指定されることも認められます。 タイプ 12 の 01 (最初の) ドキュメントと、12 02 のようなバイナリ。 タイプ 12 の 2 番目のドキュメント。場合によっては、プログラムを構築するために追加のツール (コンパイラー、インストーラー ジェネレーターなど) が必要になります。 それらの。 プログラムは納品物には含まれていませんが、組み立てに必要です。 解決策は、それらを 12 03 として指定することです。 タイプ 12 の 3 番目の文書。
19.104-78。 基本的な碑文
承認シート (AL) とタイトル ページの 2 つのドキュメントについて説明します。 ESPD の承認シートには、文書を承認した当局と、開発者、規範検査官、受入担当者などの両方の署名が含まれています。 それらの。 企業にとって非常に多くの機密情報が含まれています。 したがって、標準では、LU が開発企業に残り、特別な指示があった場合にのみ送信されると想定しています。 もう一度言いますが、LU は文書の一部ではなく、いわば別個の文書であり、別個の行として仕様に含まれています。文書自体から LU を分離する際の最初は混乱を招く奇妙な点には、十分な理由があります。
- すでに述べたように、企業は開発者に関する情報を開示したくないことがよくあります。 LU を分離して「圧縮」することで、これが可能になります (ESKD とは異なり、ESPD では文書シートにスタンプがありません。すべての情報は LU 内でのみローカライズされます)。
- 多くの企業では、混合ドキュメント フローを使用しています。つまり、オリジナルのドキュメントは企業アーカイブに電子的に保存され、そのドキュメントに含まれるドキュメント (オリジナルの署名付き) は紙の形式で保存されます。
LU には番号が付けられておらず、最初のページがタイトル ページであり、番号が配置されている最初のページはタイトル ページの隣にあることにも注意してください。 ただし、複数の LU がある場合 (すべての署名がシートに収まらない場合にこれが発生します)、LU には個別に番号が付けられます。
19.105-78。 プログラム文書の一般要件
実行方法に関係なく、ドキュメントの一般的な構造が紹介されます。 それらの。 1978 年に、文書は必ずしも紙である必要はないという規格が定められていました。 特に、コンテンツの概念は完全に電子化されたドキュメントに導入されます。 紙の実行には、当時一般的であった GOST 19.106-78 が採用されました。現在、文書の主要部分の順序を忘れない限り、この標準を参照する必要はほとんどありません。
19.106-78。 印刷されたプログラム文書の一般要件
ESPD による最も包括的な標準であり、R スキームの記述に次いで 2 番目です。 これは、文書を作成する際の主な作業標準です。 テキスト、文書構造要素、画像、数式などの書式設定に関するルールを紹介します。 ただし、ESKD の対応する 2.106 とは異なり、19.106 は詳細が大幅に劣っており、多くの不確実性が生じます。まず、この規格では行間隔や見出し間の垂直方向のスペースの量が実際には定義されていません。 彼は、スペースを決定するための 3 つのルール、つまりタイプライターで書かれたテキスト、機械、活版印刷のルールを紹介しました。
タイプスクリプトとは、タイプライターでタイプされたテキストのことです。 前の行に対する次の行の移動は、いわゆる「キャリッジ リターン」、つまり特別なレバーを動かすことによって次の行の印刷への移行中に自動的に実行されます。 通常、間隔は紙送りシャフトを回転させることで手動で調整でき、間隔サイズを 1 倍または 2 倍に設定できる「設定」がありました。
マシンタイプはおそらく印刷されたテキストです。 しかし、彼にとっては、結果がマイクロフィルム化に適しているに違いないという兆候しかありません。 これは 13.1.002-2003 への暗黙の参照であり、残念なことに、手書き文書に対してのみ行間隔 (ついでに最小フォント高さ) を設定します (条項 4.2.5)。
タイポグラフィック - 印刷所でタイプされたテキスト。 この規格が採用された年を考慮すると、おそらく次のことについて話していると思われます。
[活版印刷。行間は使用する種類によって決まります。 私はタイポグラフィーの専門家ではありませんし、現時点では植字方法に関する情報がほとんどありません。
最終的にどの間隔を使用するかは、多くの場合、地域の規制やガソリンスタンドによって決定されます。 一般的な値は 1.5 の間隔とフォント サイズ 14 です。
文書の構成方法によって多くの疑問が生じることがよくあります。 19.106 では、文書全体がセクション、サブセクション、段落、およびサブ段落に分割されているとみなします。 すべて (セクションとサブセクションを除く) にはタイトルがある場合とない場合があります。 ここで:
- 「文書の内容には、タイトルのあるセクション、サブセクション、条項、および下位条項の数が含まれます」（条項 2.1.4）。 これは、副節にタイトルがあり、目次に含められる可能性があることを直接示しています。
- 「セクションとサブセクションの見出しの間、サブセクションと段落の見出しの間にテキストを配置することが許可されています。」 番号のないテキストは見出しの間、および上部の 2 レベルにのみ配置できることに注意することが重要です。
この規格には多くの「穴」と矛盾があります。 たとえば、次のように言われています。「特定の文書内に複数のイラストがある場合、その文書全体にアラビア数字で番号が付けられます。 「しかし、イラストが 1 つしかない場合、番号が振られていない場合、どうやってそれを参照できるでしょうか。 テーブルについても同様です。 脚注については、GOST では文書全体またはページ内での番号付けの方法が示されていません。
テーブル。 文書自体には GOST 1.5.68 への参照が含まれています。 最初のエピソードから判断すると、これが標準開発の標準であると結論付けるのは簡単です。 彼がそれと何の関係があるのかは不明だ。 意味としては、これは、若干の例外を除き、ESKD のテーブル設計の規則に対応しています。 この標準はキャンセルされ、数回の反復を経て 1.5-2012 までに置き換えられ、テーブル設計ルールは単純に消滅しました。 1.5-2002 には存在していましたが、1.5-2004 ではすでに消えていました。 実際には、ESKD に従ってテーブルを作成します。
アプリケーション。 この規格では、付録の図、式、表が一般リストに含まれるかどうかは示されていません。 同様に、目次に独自のセクションや段落などが含まれる場合、そのアプリケーションの構造を開示する必要があるかどうかについては言及されていません。 私たちの実務では、アプリケーションの内部を公開することはありません。
最後に、インデントについて触れておく必要があります。 5 文字の段落インデントは、次の場合に一般的です。
- レッドライン;
- セクション (サブセクション、節、サブ節) の後の文書構造要素のインデント。
- 列挙要素。
この場合、インデントされた行の次の行にあるテキストは左余白に揃えられます。 多くの場合、インデントがジャンプするときにエラーが発生します (赤い線 - 1 つの値、項目番号 - 間隔が異なる場合、リスト内のネストされたインデント内) - これは通常必要です。
次のパートでは、ESPD 標準のリストの最後に到達する予定です。
GOST 19.001-77 一般規定
GOST 19781-90 の用語と定義。
GOST 19.101-77 プログラムとプログラム文書の種類
GOST 19.102-77 開発段階
GOST 19.103-77 プログラムおよびプログラム文書の指定
GOST 19.104-78 基本的な碑文
GOST 19.105-78 プログラム文書の一般要件
GOST 19.106-78 印刷されたプログラム文書の要件
GOST 19.201-78 技術仕様、内容および設計の要件
GOST 19.202-78仕様。 コンテンツとデザインの要件
GOST 19.301-79 テストプログラムと方法論。 コンテンツとデザインの要件
GOST 19.401-78 プログラムテキスト。 コンテンツとデザインの要件
GOST 19.402-78 プログラムの説明
GOST 19.403-79 オリジナルホルダーのリスト
GOST 19.404-79 説明メモ。 コンテンツとデザインの要件
GOST 19.501-78 フォーム。 コンテンツとデザインの要件
GOST 19.502-78 アプリケーションの説明。 コンテンツとデザインの要件
GOST 19.503-79 システム プログラマ ガイド。 コンテンツとデザインの要件
GOST 19.504-79 プログラマーズ ガイド。 GOST 19.505-79 取扱説明書の内容と設計の要件。 コンテンツとデザインの要件
GOST 19.506-79 言語の説明。 コンテンツとデザインの要件
GOST 19.507-79 運用文書のリスト
GOST 19.508-79 メンテナンスマニュアル。 コンテンツとデザインの要件
GOST 19.601-78 複製、会計および保管に関する一般規則
GOST 19.602-78 印刷によって作成されたプログラム文書の複製、会計および保管に関する規則。 方法
GOST 19.603-78 変更に関する一般規則
GOST 19.604-78 印刷されたプログラム文書を変更するための規則
技術的なタスク。
コンテンツとデザインの要件
GOST 19.201-78
01.01から。 1980年
この規格は、目的や範囲に関係なく、コンピュータ、複合体、およびシステム用のプログラムまたはソフトウェア製品の開発のための技術仕様を構築および準備するための手順を確立します。
この規格は ST SEV 1627-79 に完全に準拠しています。
1. 一般条項
1.1. 委託条件は、GOST 19.106-78 に従って、GOST 2.301-68 に従ってフォーマット 11 および 12 のシートに作成され、原則としてシートのフィールドに記入する必要はありません。 シート (ページ) 番号は、シートの上部のテキストの上に配置されます。
1.2. 承認シートとタイトルページは、GOST 19.104-78 に従って作成されます。
情報部分（注釈や内容）、変更登録シートは文書に含まれない場合があります。
1.3. プログラムまたはソフトウェア製品の開発の後続段階で技術仕様に変更または追加を行うために、追加仕様がリリースされます。 技術仕様への追加の調整と承認は、技術仕様で確立されたのと同じ方法で実行されます。
1.4. 委託条件には次のセクションが含まれている必要があります。
導入;
· 開発の根拠。
· 開発の目的。
· プログラムまたはソフトウェア製品の要件。
· ソフトウェア文書の要件。
· 技術的および経済的指標。
· 開発の段階と段階。
· 管理および受け入れ手順。
· アプリケーションは技術仕様に含まれる場合があります。
プログラムやソフトウェア製品の機能に応じて、セクションの内容を明確にしたり、新しいセクションを導入したり、個々のセクションを結合したりすることができます。
2.1. 「はじめに」には、プログラムまたはソフトウェア製品の名前、適用範囲、およびプログラムまたはソフトウェア製品が使用される目的の簡単な説明を記載します。
(変更版、修正第1号)
2.2. 「開発の基礎」セクションには次のことを示す必要があります。
· 開発が実行されるベースとなる文書。
· この文書を承認した組織とその承認日。
· 開発トピックの名前および (または) シンボル。
(変更版、修正第1号)
2.3. 「開発の目的」セクションには、プログラムまたはソフトウェア製品の機能および運用の目的を示す必要があります。
2.4. 「プログラムまたはソフトウェア製品の要件」セクションには、次のサブセクションを含める必要があります。
· 機能特性の要件。
· 信頼性の要件。
・ 利用規約;
· 技術的手段の構成とパラメータの要件。
· 情報とソフトウェアの互換性の要件。
· ラベルと包装の要件。
· 輸送と保管の要件。
· 特別な要件。
(変更版、修正第1号)
2.4.1. 「機能特性の要件」のサブセクションでは、実行される機能の構成、入出力データの構成、タイミング特性などの要件を示す必要があります。
2.4.2. 「信頼性要件」の項には、信頼性の高い動作を保証するための要件（安定した動作の確保、入出力情報の監視、障害後の回復時間など）を示す必要があります。
2.4.3. 「動作条件」のサブセクションには、指定された特性が保証される動作条件（選択された種類の記憶媒体の周囲温度、相対湿度など）、サービスの種類、必要な数および資格を示す必要があります。人事。
2.4.4. 「技術的手段の構成およびパラメータの要件」のサブセクションでは、技術的手段の必要な構成が示され、その主な技術的特徴が示されます。
2.4.5. 「情報とソフトウェアの互換性の要件」では、入出力時の情報構造、解決方法、ソースコード、プログラミング言語、プログラムで使用するソフトウェアの要件を示す必要があります。
必要に応じて、情報とプログラムの保護を確保する必要があります。
(変更版、修正第1号)
2.4.6. 「マーキングおよびパッケージ化の要件」のサブセクションでは、一般に、ソフトウェア製品のマーキングの要件、パッケージ化のオプションおよび方法が示されています。
2.4.7. 「輸送および保管の要件」には、ソフトウェア製品の輸送条件、保管場所、保管条件、保管条件、さまざまな条件での保管期間を示す必要があります。
2.5a。 「プログラム文書の要件」セクションには、プログラム文書の予備構成と、必要に応じてその特別な要件を示す必要があります。
(追加導入、修正第 1 号)。
2.5. 「技術的および経済的指標」のセクションには、推定経済効率、推定年間需要、国内外の最高のサンプルまたは類似品と比較した開発の経済的利点を示す必要があります。
2.6. 「開発の段階と段階」のセクションでは、開発に必要な段階、作業の段階と内容（開発、合意、承認が必要なプログラム文書のリスト）が確立されており、また原則として、開発期間と実行者が決定されます。
2.7. 「管理と受け入れの手順」セクションには、テストの種類と作業の受け入れに関する一般要件を示す必要があります。
2.8. 技術仕様の付録には、必要に応じて次のことが記載されています。
開発を正当化する研究およびその他の研究のリスト。
アルゴリズム図、表、説明、根拠、計算、および開発中に使用できるその他の文書。
他の開発ソース。
ソフトウェアドキュメントの要件、
印刷済み
GOST 19.106-78
1.5. プログラム文書は以下によって作成されます。
A4 形式のシート (GOST 2.301-68) - タイプライターまたは手書きで文書を作成する場合 (フォーム 1)。 A3用紙へのデザインも可能です（様式2）。
機械でドキュメントを作成する場合、データ出力デバイスの出力特性によって提供される、A4 および A3 フォーマットのシートに印刷されます。 A4 および A3 フォーマットに対応するシートのサイズの偏差は、使用される技術的手段の能力によって決定され、許容されます。
活版印刷フォーマットのシート上 - 活版印刷方法を使用して文書を作成する場合。
プログラムドキュメントの資料は次の順序で配置されています。
タイトル部分：
§ 承認シート (文書の総枚数には含まれません)。
§ タイトルページ (文書の最初のページ);
§ 情報部分:
§ 注釈;
§ 主要部分：
§ 文書テキスト (写真、表などを含む)。
§ アプリケーション;
§ 用語のリスト。
§ 略語のリスト。
§ 図面のリスト。
§ テーブルのリスト。
§ 主題索引。
§ 参考文献のリスト。
§ 記号と数値係数のリスト。
§ 登録部分の変更:
§ 登録シートを変更します。
必要に応じて、付録、用語リスト、略語リスト、図表、主題索引、参考文献リスト、記号および数値係数のリストが作成されます。
(変更版、修正第1号)
1.7. 用語と略語のリスト、主題索引、記号と数値係数のリストは、アルファベット順に編集する必要があります。
残りのリストは番号の昇順にコンパイルされます。
(追加導入、修正第 1 号)
2. ほとんど連続したテキストを含むソフトウェア ドキュメントの要件。
2.1. 文書の構築。
2.1.1. 必要に応じて、文書を複数の部分に分割することができます。 部品への分割はセクション以上のレベルで行われます。 各部品は個別に供給されます。 すべての部品には、GOST 19.103-77 に従って文書指定が割り当てられます。
各部分はこの規格の要件に従って作成され、最初の部分の内容の最後に残りの部分の名前がリストされます。
プログラム テキストが記述されている言語の規則に従ってフォーマットされたプログラム テキストの一部をドキュメントに含めることができます。
ドキュメントのページの番号付け、およびセクション、図、表の番号付けは、各パート内で実行されます。 各パートはタイトルページから始まります。
セクションとサブセクション内でドキュメントのページに個別の番号を付けることは許可されません。
承認シートは、最初の部分を示す文書全体に対して発行されます。
2.1.2. プログラム文書の情報と主要部分は、次の形式 1 または 2 で実行されます。
フィールド 1 - ページのシリアル番号。
フィールド 2 - 文書の指定。
フィールド 3 - 文書テキスト。
フィールド 4 - 行を変更します。 GOST 19.604-78 の要件に従って記入されます。
原稿ページフォーマットのフレーム（枠線）が適用されない場合があります。
2.1.3. 要約は「ABSTRACT」という見出しが付いた別の (番号付き) ページに配置され、セクションとして番号は付けられません。
注釈はプログラムのエディションを示し、文書の目的と内容を簡単に説明します。 文書が複数の部分で構成されている場合、部分の合計数が注釈に示されます。
コンテンツに含まれる名称は小文字で表記しております。 大文字および略語は大文字で印刷する必要があります。
2.1.3、2.1.4。 (変更版、修正第 1 号)。
2.1.5. 各文書のテキストは、文書が部分、セクション、およびサブセクションに分割されているかどうかに関係なく、必要に応じて段落に分割され、段落がサブ段落に分割されます。
2.1.6. 文書テキストの構造要素は、セクション、サブセクション、段落、サブ段落、および列挙です。
セクション - 分割の最初の段階。番号で示され、見出しが付けられます。
サブセクション - セクションの一部であり、番号で指定され、見出しが付いています。
項目はセクションまたはサブセクションの一部であり、番号で示されます。 タイトルが付いている場合があります。
サブ項目 - 番号で示される項目の一部には見出しが付いている場合があります。
段落は、番号のない論理的に分離されたテキストの部分です。
文書のテキストにセクションがない場合、その最初の構造要素は段落です。
セクションとサブセクションの見出しの間、サブセクションと段落の見出しの間にテキストを配置することができます。
サブセクション、段落、およびサブ段落内では、リストを指定できます。リストは、1)、2) などのように括弧付きのアラビア数字で示すことをお勧めします。テキストの前にハイフンを置くことでリストを強調表示することができます。
各構造要素は段落インデントで始まります。
(変更版、修正第 1 号)。
2.1.7. セクション見出しは大文字で書かれ、テキストの左右の境界線に対して対称に配置されます。
サブセクションの見出しは、段落から小文字で書かれます (最初の大文字を除く)。
文書を機械で印刷する場合、印刷デバイスで使用可能なフォントでサブセクションや段落の見出しを書くことができます。
見出し内の単語のハイフンは許可されません。 タイトルの末尾にピリオドはありません。
タイトルが 2 つの文で構成される場合、それらはピリオドで区切られます。
(変更版、修正第 1 号)。
2.1.8. 見出しと次のテキストの間、およびセクションとサブセクションの見出しの間の距離は、以下に等しい必要があります。
タイプライターで文書を実行する場合 - 2 つの間隔。
手書きの場合 - 10 mm;
機械で行う場合 - 少なくとも 3 つのフォントの高さ。
テキストが前のセクションのテキストと同じページに書かれているセクションおよびサブセクションの場合、テキストの最後の行と後続の見出しの間の距離は次の値に等しくなければなりません。
タイプライターによる方法を使用して文書を実行する場合 - タイプライターによる 3 つの間隔。
手書きの場合 - 少なくとも 15 mm。
機械で行う場合 - 少なくとも 4 つのフォントの高さ。
タイトル行の底辺間の距離は本文と同じです。
印刷方法を使用してドキュメントを発行する場合、指定された距離は印刷出版物の規則に従って計算されます。
2.1.9. セクション、サブセクション、段落、およびサブ段落には、ドット付きのアラビア数字で番号を付ける必要があります。
セクションには連続番号 (1、2 など) が必要です。
セクション内では、このセクションに含まれるすべてのサブセクション、段落、およびサブ段落に連続した番号を付ける必要があります。
サブセクションの番号付けには、セクション番号と、このセクションに含まれるサブセクションのシリアル番号がドットで区切られて含まれます (2.1、3.1 など)。
セクションとサブセクションがある場合は、節とサブ節のシリアル番号 (3.1.1、3.1.1.1 など) がドットの後のサブセクション番号に追加されます。
プログラム文書のテキストの構造とそのセクション、サブセクション、段落、およびサブ段落の番号付けの例は、付録 2 を参照してください。
(変更版、修正第 1 号)。
2.1.10. (削除、修正第 1 号)
2.2. ドキュメントのテキスト。
2.2.1. 文書の本文は、誤解の可能性を排除し、短く明確にする必要があります。
用語と定義は統一されており、確立された基準に準拠している必要があり、それらが存在しない場合は、科学および技術文献で一般的に受け入れられており、用語のリストに記載されている必要があります。
2.2.2. GOST 2.316-68に従って、テキスト内の単語の略語およびイラストの下の碑文が許可されます。 この文書で採用され、GOST 2.316-68 に含まれていない追加の略語は、受け入れられる略語のリストに記載する必要があります。
2.2.3. 個々の概念を強調するために、単語間の間隔を変更したり、個々の単語やテキストの一部を本文とは異なるフォントで印刷したりすることができます。例:
UNCATLG - ソース データ セットに関連付けられたディレクトリ エントリを除外する必要があることを示します。TO = device = list - 対象となるストレージ メディアを示します...ABC3-91 構文エラーの原因。 メッセージで指定されている...SYSTEM ACTION。 タスクは実行されません...プログラマーアクション。 提供する必要があります...
2.2.4. 文書の本文に対する必要な説明は脚注に記載できます。
脚注は、フォントの上端のレベルに配置された括弧付きの数字によって示されます (例: 「printing device2)...」または「paper5)」。
脚注が単一の単語を参照する場合、脚注記号はこの単語のすぐ隣に配置されますが、文全体を参照する場合は文の最後に配置されます。 脚注テキストはページの最後に配置され、ページの左側に引かれた 3 cm の長さの線によって本文から分離されます。
2.3. イラスト。
2.3.1. 図は文書の本文および (または) 付録に配置できます。
特定の文書内に図が複数ある場合、文書全体にアラビア数字で番号が付けられます。
付録では、文書の本文に対して確立された順序で、各付録内の図に番号が付けられます。
イラストには、テーマ別のタイトルと、イラストの内容を説明するキャプション テキストが含まれる場合があります。
テーマの見出し (名前) はイラストの上に配置され、キャプション テキストはその下に配置されます。 説明データの下にはイラスト番号が記載されています。
(変更版、修正第 1 号)。
2.4. 数式。
2.4.1. 文書内の数式が複数ある場合、その数式はアラビア数字で番号が付けられ、ページの右側に数式レベルの括弧内に配置されます。
文書全体またはその部分内で、文書が複数の部分に分割されている場合、式には連続した番号が付けられます。
文書をパーツに分割する場合、パーツ番号は式のシリアル番号の前に配置され、最後のドットから区切られます (例: 「式 (1.4) 内」)。
2.4.2. 式に含まれる記号や数値係数の意味は、式のすぐ下に記載する必要があります。 各文字の意味は、式で指定された順序で新しい行に出力されます。 トランスクリプトの最初の行は、その後にコロンを付けずに、「where」という単語で始まる必要があります。
プログラムドキュメントにこれらの記号と数値係数のリストが含まれている場合、式の下の値が与えられない場合があります。
(変更版、修正第 1 号)。
2.4.3. 1 つのドキュメント内の同じパラメータの次元は一定である必要があります。
2.5.1. プログラム文書では、標準（企業標準を除く）、技術仕様およびその他の文書（たとえば、国家監督機関の文書、ソ連国家建設委員会の規則および規制）への参照が許可されます。 規格および技術仕様に言及する場合は、その名称を示します。
文書全体またはそのセクションを参照する必要があります (文書の指定と名前、セクションまたは付録の番号と名前を示します)。 セクションまたはアプリケーションへの参照を繰り返す場合は、番号のみが示されます。
文書および（または）セクションの名前を示さずに、その名称のみを示すこともできます。 別の文書の個々のサブセクション、段落、図への参照は許可されません。 ドキュメント内の段落、図、および個々のサブセクションへのリンクは許可されます。
(変更版、修正第 1 号)。
2.6. テーブル
2.6.1. 指標の視認性と比較性を向上させるために、デジタル資料は通常、表の形式で提示される必要があります。
2.6.2. テーブルは GOST 1.5-68 の要件に従って準備する必要があります。
テーブルにはタイトルが付いている場合がありますが、タイトルは小文字にする必要があります。 大文字および略語は大文字で印刷する必要があります。
(変更版、修正第 1 号)。
2.6.3. 表の脚注は表のすぐ下にあります。 例えば：
印刷に使用されるデータセット
目的
規格名
使用デバイス
情報の印刷用
SSSSSSS1) 印刷デバイス2)
プログラム実行中の印刷用
RRRRRRRR 印刷装置2)
1) オペレーティング システムを構成するときに、名前 SSSSSSS を指定する必要があります。
2) I/O 操作による CPU のダウンタイムを軽減するために、磁気テープを使用できます。
2.7. ノート。
2.7.1. 本文および表の注記は、参考データおよび説明データのみを示します。
1つのノートには番号が付いていません。 「メモ」という単語の後にピリオドを置きます。
いくつかの音符には、ドット付きのアラビア数字を使用して順番に番号を付ける必要があります。 「メモ」という単語の後にコロンを入力します。
例えば：
注記。
注: 1. 2.
2.7.2. メモのテキストは 1 つの間隔でのみ印刷できます。
2.8. 略語。
2.8.1. 以下の場合を除き、テキストおよびイラストの下の碑文内の単語の略語は許可されません。
GOST 2.316-68 で確立され、ロシア語で一般的に受け入れられている略語。
タスク制御言語、プログラム構成ツールなどで、プログラム、その部分および動作モードを指定するために使用される略語。ラテン文字で指定されるものも含まれます。
文書で単語または名前の特別な略語システムが採用されている場合は、受け入れられる略語のリストが含まれている必要があります。
(変更版、修正第 1 号)。
2.9. アプリケーション
2.9.1. 図解資料、表、またはサポートテキストは、付録の形式で提供される場合があります。
申請書は、この文書の後続ページとして作成されるか、別の文書として発行されます。
2.9.2. 各申請書は、右上隅に「APPENDIX」という単語で示された新しいページで始まり、本文と対称的に大文字で書かれた主題の見出しを持たなければなりません。
文書内に複数の付録がある場合、付録 1、付録 2 などのように、すべての付録にアラビア数字 (No. 記号なし) で番号が付けられます。
申請書を別の書類として発行する場合は、タイトルページの書類名の下に「APPENDIX」と記載し、複数の申請書がある場合には通し番号も記載する必要があります。
別の文書として発行された付録は、文書の一部として指定されます。 必要に応じて、このようなアプリケーションに「コンテンツ」を配置できます。
複数のアプリケーションを結合して、プログラム ドキュメントの別個の部分にすることができます。
(変更版、修正第 1 号)。
2.9.4. 文書および文書に含まれる付録のページ番号は、付録が別個の文書として作成されない限り、連続していなければなりません。
付録の図と表には、各付録内で番号が付けられています。
(変更版、修正第 1 号)。
すべての添付ファイルはコンテンツ シートにリストされている必要があります。
3. グラフに分割されたテキストを含むソフトウェア ドキュメントの要件。
3.1. グラフに分割されたテキストを含むプログラム文書は、必要に応じて、番号のないセクションとサブセクションに分割されます。 行と列を区切る線を引かなくてもかまいません。
3.2. セクションおよびサブセクションの名前は見出しとして小文字 (最初の大文字を除く) で書かれ、下線が引かれています。
見出しと次のテキストの間、テキストと次の見出しの間、および見出しの間の距離は、第 2.1.8 項で指定された距離に一致する必要があります。
3.3. 文書内の注記は、第 2.7 項に規定されている順序で作成されます。
3.4. 行のあるテーブルやフォームでは、すべてのレコードが 1 つの行の各行に配置されます。
レコードは行と列を区切る線と結合しないでください。
セクションとサブセクションの間、および大きな文書ではセクションとサブセクション内にも自由行を残す必要があります。
ドキュメントの列に数行のテキストが書かれている場合、後続の列では最初の行のレベルからエントリが始まります。 エントリが 1 行を占める場合は、最終行のレベルにエントリを配置できます。
(変更版、修正第 1 号)。
付録 1
情報
GOST 19.106-78 への準拠に関する情報データ
ST SEV 2088-80
秒 1 GOST 19.106-78 のセクションに対応します。 1と秒。 4 (第 4.1 条) ST SEV 2088-80。
秒 2 GOST 19.106-78 のセクションに対応します。 4 (条項 4.4 ～ 4.9) ST SEV 2088-80。
(追加導入、修正第 1 号)。
付録 2
情報
プログラム文書の本文の構造
基本的な説明
プログラム文書化のための統合システム。
1978 年 12 月 18 日付けのソ連国家基準委員会令第 3351 号により、導入日が定められました。
1980 年 1 月 1 日から
この規格は、実装方法に関係なく、ESPD 規格で規定されているプログラム文書の承認シートとタイトルページの主な記載事項を記入するための形式、サイズ、位置、および手順を確立します。
この規格は、承認シートおよびタイトル ページのデザインに関して ST SEV 2088-80 に準拠しています (参考付録 1 を参照)。
1. 基本規定
1.1. プログラム文書の承認シートとタイトルページの主な記載には、次の構造データが含まれます。
省（部局）の名前。
文書のタイトル。
文書指定。
原本が提出されたデータ媒体に関する情報。
稟議書の総枚数、書類の量。
開発者に関する情報。
規制検査官ビザ;
登録と保管の記録。
変更に関する情報。
2. 承認シート（LA）の基本説明
2.1. 承認シートは、文書の種類に関係なく、プログラム文書ごとに A4 用紙 (GOST 2.301-68) で発行され、任意のデータ媒体で実行できます。
2.2. 承認シートの指定は、承認シートが関連する文書の指定をハイフン (LU コード) で区切って構成されます。
承認シートは書類の総枚数に含まれません。
2.3. 承認シートには複数のシートが含まれる場合があり、その場合は各シートに番号が付けられます。 1枚目は承認シートに含まれるシートの総数を示します。
2 回目以降の承認シートは、第 2 項に従って作成されます。 1 GOST 19.106-78 に準拠していますが、「文書テキスト」フィールドには、承認シートの最初のシートに収まらない人の役職と署名が記載されています。
2.4. 承認シートは、承認された文書の後に仕様書に組み込まれ、元の文書を保管する企業に保管されます。
この仕様書には仕様承認書も含まれます。
承認シートのコピーは顧客と親会社に送信されます。
お客様の特別な許可があれば、承認シートを他の組織に送信することができます。
2.5. 承認シートは、図に示されているフォームに従って記入されます。
フィールド 1 - この文書を作成した組織がシステムに含まれる省庁または部門の名前。
お客様のご要望により記入させていただきます。
必要に応じて、フィールド 1 の右上隅に特別なマークが配置されます (機密スタンプ、「企業から削除しないでください」という表示など)。
フィールド 2 - フィールドの左側 - 顧客の組織からの文書を承認した人の役職と署名 (必要に応じて) フィールドの右側 - 顧客の組織から文書を承認した人の役職と署名開発者の組織。
調整および承認する組織、および役人の特定の署名は、省庁によって規制されています。
文書のタイトルは省略したり、プログラムのタイトルと組み合わせたりすることができます。
データ メディアの種類は、ドキュメントがデータ メディア上で実行される場合にのみ示されます。
フィールド 5 - 承認シートの合計数 (例: 「シート 3」)。 1 つのシートでは、フィールド 5 は入力されていません。
フィールド 6 - フィールドの右側 - 文書を発行した組織の責任者、文書を作成した部門の責任者、開発マネージャー (開発者)、文書を作成した者、および文書を作成した者の役職と署名規範検査官。
各署名の右側には、文書に署名した人のイニシャルと姓があり、署名の下には署名した日付が表示されます。
一致する署名が多数ある場合、それらはフィールド 2 の左側またはフィールド 6 の左側に配置されます。
他の職員のビザが文書で必要な場合は、LU を提出するための欄に置かれます。
フィールド 9 - GOST 19.604-78 に基づく変更行。
フィールド 10 - 文書レター。
LU の記入例は、付録 2 を参照してください。付録の署名の数は条件付きで与えられます。
3. タイトルページの基本説明
3.1. タイトル ページは、LU 用に確立された形式と規則に従って記入されますが、次のとおりです。
フィールド 1 - 顧客の要求に応じて入力されます。
フィールド 2 - 入力しないでください。
フィールド 3 - プログラムまたはソフトウェア製品の完全名 (大文字)、名前およびドキュメントの種類。
ドキュメントのタイトルは省略したり、製品のタイトルと組み合わせたりすることができます。 プログラムまたはソフトウェア製品の短縮名を示すことができます。
フィールド 4 - 文書の指定とデータキャリアのタイプの表示。
データ キャリアのタイプは、プログラム ドキュメントがデータ キャリア上で実行される場合にのみ示されます。
フィールド 5 - 文書の量を示します。
フィールド 6 - 入力しないでください。
フィールド 7 - 文書の発行 (承認) 年 (「年」または「y」という単語は示されません)。
フィールド8 - GOST 19.601-78に基づく会計および保管に関するマーク。
フィールド 9 - GOST 19604-78 に基づく変更行。
フィールド 10 - 文書レター。
3.2. タイトルページの左上隅に次のような碑文があるはずです。
承認済み---------------------指定LU
タイトルページの記入例は、付録 3 を参照してください。
4. 文書本文の基本的な記述。
付録 1
情報
GOST 19.104-78 への準拠に関する情報データ
ST SEV 2088-80
秒 1 および 2 GOST 19.104-78 のセクションに対応します。 2 ST SEV 2088-80
秒 3 GOST 19.104-78 のセクションに対応します。 3 ST SEV 2088-80
付録 2
情報
承認シートの記入例
同意しました
中央臨床病院院長
(署名) A.A. ペトロフ
承認しました
部長
(署名) N. N. シゾフ
機械のオペレーティングシステム
ローダ
プログラマーズガイド
承認書
A.V.00001-01 33 01-1-LU
(記憶媒体の種類)
同意しました
CCの責任者
(署名) I.I.パブロフ
工場の主任技術者
(署名) A.A.イワノフ
代表者
開発会社
チーフエンジニア
NIIアフトマティカ
（署名）A.V.バソフ
12部門の責任者
(署名) G.F.シゾフ
開発責任者
（署名）L.A.ソコロフ
執行者
(署名) A.M. パシン
標準コントローラ
(署名) G.V. グロモバ
付録 3
情報
タイトルシートの記入例
承認された
A.V.00001-01 33 01-1-LU
統合電子計算システム
機械のオペレーティングシステム
ローダ
プログラマーズガイド
A.V.00001-01 33 01-1
(記憶媒体の種類)