GOST 34に準拠した技術仕様の開発はシンプルで簡単です

多くの場合、GOST 34（TK）に準拠した参照条件の準備は面倒なだけでなく、非常に迷惑でもあるという意見を耳にします。なぜなら、あらゆる種類のナンセンスな水をたくさん書かなければならないからです。 しかし、考えてみてください。研究機関全体がこのGOSTの開発に携わっており、州レベルのプロジェクトであり、何百もの自動化プロジェクトの経験、複雑なプロジェクトがまとめられました。 彼らは本当にナンセンスを書くことができますか？



実際、GOSTは有能なアプローチにより、技術仕様の開発だけでなく、自動化プロジェクト全体の実装中（および国家契約だけでなく、商業開発にも）に大いに役立ちます。 優秀な人が書いた。 しかし、彼らの労働の成果を活用するには、TKだけでなくGOST 34全体の概念を少し理解する必要があります。



この記事では、GOSTのすべての要件をポイントごとに分析し、GOST 34に基づいたTKの開発を負担ではなく、プロジェクトの大きな助けとするようにします。

1.記事は何ですか？

多くの場合、GOST 34（TK）に準拠した参照条件の準備は面倒なだけでなく、非常に迷惑でもあるという意見を耳にします。なぜなら、あらゆる種類のナンセンスな水をたくさん書かなければならないからです。 しかし、考えてみてください。研究機関全体がこのGOSTの開発に従事し、州レベルのプロジェクトであり、何百もの自動化プロジェクトの経験、複雑なプロジェクトが一般化されました。 彼らは本当にナンセンスを書くことができますか？



実際、有能なアプローチにより、GOSTは技術仕様の開発だけでなく、自動化プロジェクト全体の実装中（および国家契約だけでなく、商業開発のため）に大いに役立ちます。 優秀な人が書いた。 しかし、彼らの労働の成果を活用するには、TKだけでなくGOST 34全体の概念を少し理解する必要があります。



ところで、TKは自動化プロジェクト中に開発された最初のドキュメントではありません。 これは、1.5項で明示的に述べられています。 GOST 34.602-89：「原子力発電所のTKは、「原子力発電所の建設の研究と正当化」段階の最終文書に含まれるデータを含む初期データに基づいて開発されます。 詳細については、私の記事「 情報システムの開発中の設計前調査 」を参照してください。

注意：この記事の目的は、GOSTを置き換えることではなく、その条項の一部を説明することです。

2. GOST 34に準拠した技術仕様の特徴

2.1。 ToRはどの標準でコンパイルされていますか？

GOST 34に基づくTKの標準の正式名称は次のとおりです。GOST34.602-89「情報技術（IT）。 自動化システムの一連の標準。 自動化システムの作成のための参照条件。」



標準自体は15ページのみに印刷されます（はい、かなり）。 言語はロシア語で、本当にロシア語であり、キリル文字に異星人ではありません。 つまり、GOSTのテキストも連邦法も学位論文も、単なる人間には理解できないように前もって頭を駆り立てない場合、初めてではありませんが、読んで浸透することは非常に可能です。



実際、この標準では多くのあいまいな用語が使用されています。 たとえば、言語サポートとはどういう意味ですか？ 使用される概念を明確にするために、GOST 34.003-90「情報技術（IT）」を参照する必要があります。 自動化システムの一連の標準。 自動化システム。 用語と定義。」

2.2。 参照条件にGOSTが必要なのはなぜですか？

おそらく、新しいドキュメントを作成する必要がある場合は、インターネット上でそのようなドキュメントのテンプレートを探しているか、同僚にそれを求めています。 したがって、ドキュメントまたはプロセスの標準はテンプレートです。 さらに、テンプレートはドキュメントの開発を大幅に簡素化します。構造とコンテンツはすでに考慮されています。さらに、このようなテンプレートでは、覚えていないような瞬間が考慮されます。

2.3。 参照条件はプロジェクトでどのような役割を果たしますか？

標準RD 50-682-89のパラグラフ1.7によれば、「参照条件は、AUの作成と顧客による受け入れが実行される主要文書です。」 そして、これは本当に主要な文書です。 システムの開発と実装に必要なすべてを記述する必要があります。



TORは、システムの全体的な外観、作業量（開発フレームワーク）、および開発と承認の手順を確立します。 すべてがTKで始まり、すべてがTKで終わります。 このドキュメントは、顧客がタスクの重要性と複雑さ、そして彼がお金を払う理由を理解するのに理想的です。



さらに、自動化プロジェクトは両側のチームによって実行されるため、作業指示書は請負業者と顧客の両方に対してコンパイルされます。 どのITプロジェクトにも膨大な数の組織活動があり、顧客の積極的な参加なしにはその活動は不可能です。 あらゆる機会に顧客にこれを説明してください。そうでなければ、彼らはお金を払ってじっと座っているだけでいいという印象を持っています。 そして、プロジェクトは失敗し、ショーダウンが始まります。 一般的に、実際のチームがなければ、プロジェクトを開始する価値はありません。



TKを正式に策定しないでください。 何を書くべきかわからない場合、TKを開発するには時期尚早であり、システム、自動化されたプロセス自体、自動化オブジェクトがまだ理解されていないことを意味します。 システムの概念を作成する必要があります。これについては記事の冒頭で説明しました。

2.4。 GOST 34.602-89は何歳で、新しい規格はありますか？

時代遅れではありません。 コア以外のものはほとんど見つけることができませんでした。 そして、GOST 34が時代遅れであると主張する人は誰も単一の例を挙げることはできません（おそらくそれを読む資格を持っていなかったのでしょうか？）実際、GOSTは自動化プロジェクトに対する一般的なアプローチを説明しており、プログラミングについては語っていません。 GOST 34はそれについてではありません。



さて、他の標準との比較について話す場合、比較する特別なものはありません。 GOST 34は自動化プロジェクトの幅広い視野を提供するため、他の規格はアウトソールには適していません（私の意見では）。 はい、それらはよりシンプルです（したがって、より人気があります）が、深さは同じではありません。 自動化プロジェクトの独自の標準を開発する際に知っておくべき標準のリストを以下に示します。

• IEEE 830-1998。 ソフトウェア要件の仕様をコンパイルする方法。
• GOST R ISO / IEC 12207-2010。 情報技術。 システムおよびソフトウェアエンジニアリング。 ソフトウェアのライフサイクルプロセス。
• ISO / IEC / IEEE 29148-2011。 システムおよびソフトウェアエンジニアリング-ライフサイクルプロセス-要件エンジニアリング。
• GOST R 54869-2011。 プロジェクト管理。 プロジェクト管理要件。
• さて、GOSTシリーズ34。

3. GOST 34に準拠した技術仕様の準備に関する一般原則

3.1。 GOST 34に従って、どのスペシャリストが参照条件を作成する必要がありますか？

多くの場合、GOST 34に従ってTKをドラフトするとき、開発者は多くのことを誓います。なぜですか？ はい、それはプログラマの仕事ではないからです。 GOST 34に準拠した参照条件は、一般にプログラマーに示すことはできません。 このための技術プロジェクト文書があります。 参照条件-顧客と合意した文書。プロジェクトマネージャーのテーブルに常にあります。 TKは2つの質問に答えます。システムが行うべきことと作成する方法です。 技術プロジェクトは質問に答えます：TKの要件がどのように満たされるべきか。 たとえば、TKではログインとパスワードによる承認が必要であり、TPではインターフェイス、スクリプト、データベース構造のレイアウトを提供することを規定しています。 なぜさまざまな段階に分かれているのか、なぜプログラマーの仕事をすぐにすべきではないのか、私の記事では、情報システムを開発する際の 病院の建設と 設計前の調査 の例に関するIP（情報システム）の成功した設計の秘密を参照してください。



参照条件は、ビジネスアナリストが顧客と開発チームの間の「翻訳者」であるため、ビジネスアナリストが作成する必要があります。 ビジネスアナリストのタスクは、顧客が何を必要としているかを把握し、チームに明確な方法で表現することです。 そして、それを技術仕様の形で表現します。 さらに、ビジネスアナリストは、顧客とその従業員の声に耳を傾けるだけでなく、彼らが何を言っていないかを知る必要があります（これは通常50％以上です）。 したがって、アナリストは、自動化されているプロセスに関する十分な知識が必要であり、彼の知識により、調査結果に残ったギャップを埋めなければなりません。

3.2。 どちらの側が参照条件になるべきですか？

基本的に、参照条件は請負業者によって編集されていますか？ なんで？



GOST 34-602-89の付録1で推奨されているだけではありません。 実際、顧客には通常、適切な専門家がいません。 ただし、TKは必ず開発され、顧客によって合意されます。 そしてここでは、契約が正式ではないことを確認する必要があります。 私は常に、顧客と一緒に各項目を詳細に分析するように主張します。 あなたの目標は、顧客をプロジェクトに参加させることです。 そうでなければ、彼はシステムへの期待を形成しません。つまり、第一に、彼はどんな結果にも不満を抱き、第二に、必要な組織的手段を実行することができません。

3.3。 GOST 34からどれだけ離れることができますか？

テンプレートにも重大な欠点があります-これはテンプレートです。 つまり、右または左へのステップは、社会保護の最高の尺度です（以前に死刑が呼ばれていました）。



実際、これはそうではありません。 プロセス標準（つまり、標準はソーセージ用ではなく、一部のアクティビティ用）は、一般的な指示、概要のみを提供します。 それは、重要なものを忘れないように、世代の経験をあなたに伝えるために、そしてあなたを旗の後ろに追い込まないために作成されました。



信じられない？ 次に、GOST 34.602-89の条項2.2をお読みください（ちなみに、ハイフンの後の数字は、標準またはそのエディションの発行年です）。 TKのサブセクションを除外またはマージします。」 パラグラフ1.2でも。 RD 34.698-90は次のように述べています。「文書の内容はすべてのタイプのASに共通であり、必要に応じて、作成されたASの機能に応じて文書の開発者が補足することができます。 セクションを組み合わせたり除外したりするために、ドキュメントに追加のセクションや情報を含めることができます。



一般的に、一般的なフレーズのみを引用できる場合は、すべての善のために、すべての悪に対して-何も書かないでください。 そうでなければ、そのような文章を読んだ文書を読んでいる専門家は、文書を真剣に受け止めるのをやめ、重要なポイントを見逃してしまいます。 文書を読むことを拷問にしないでください！

3.4。 GOST 34によるTKが、システムの機能に直接関係しない非常に多くの要件を説明しているのはなぜですか？

実際、30ページのTORでは、7〜10ページのみが機能に専念できます。 これには説明があります。 実際、GOST 34の開発者は、自動化プロジェクトを私たちとはまったく異なる方法で見ていました。 そして、彼らはより正確に、より包括的に見えました。



まず 、TKの前半では、システムに関する一般的な情報と一般的な要件が与えられるだけではありません。 システムが作成されている理由、システムが自動化するプロセス、システムが機能するために必要なこと、システムの種類を理解する必要があります。 それは当たり前のことのように思えますが、それらがなければ、チームのメンバーは仕事の目標と目標を達成するための手段を異なって理解します。 白鳥、ガン、カワカマスのようにではなく、すべての参加者が同じ波に合わせられるようにすることが非常に重要です。



第二に、GOST 34のコンパイラーは、システムを主に人間として、次にハードウェアとソフトウェアの複合体として見ました。 これが、GOST 34.003-90が自動化システムを定義する方法です。「確立された機能を実行するための情報技術を実装する、人員とその活動のための自動化ツールのセットで構成されるシステム」。 したがって、情報システムは、訓練された人員、ソフトウェア、およびハードウェアの複合体であり、すべて一緒になっています。 確かに、会計士からコンピューターを奪ってください、彼らは難しいですが、紙の登録であるにもかかわらず、彼らの仕事を実行することができるでしょう。 しかし、1Cは会計士なしでは独立して機能しません。 したがって、組織的対策に関するTKの多くのセクション。 彼らが言うように、ITシステムは20％のITであり、残りはすべて組織的な対策です。 つまり、TKは、システムの実装に必要なすべてをAからZまで綴った文書です。



第三に 、GOST 34.602-89の名前に注意を払ってください：「自動化システムの作成のための参照条件」。 TKはシステム用ではなく、システムの作成用です。 違いは何ですか？ 違いは、ToRがシステム自体の要件を確立するだけでなく、その作成プロセスも規制することです。つまり、ドキュメントには、結果を達成するために必要なすべての組織的手段の要件が含まれます。 実際、自動化プロジェクトを実装するとき、多くの場合、多くのプロセスを再構築し、人員を訓練し、ハードウェアを準備する必要があります。



第4に 、TKは、チェックマークを付けることができるドキュメントです。この要件を考慮したかどうかを検討します。 たぶん、10ティックを自動的にきれいに入れます。これらは標準的なソリューションになるからです。 ただし、チェックマーク11は非常に大きな問題を明らかにします。この問題を今すぐスキップすると、すべての期限と予算が既に決定されている場合、実装プロセスのどこかにポップアップします。



5番目に 、上で述べたように、不必要なサブセクションを除外できます。これは許可されています。たとえば、デザインで特許を取得できないことが確実にわかっている場合、なぜ特許の純度要件を満たす必要があるのでしょうか？これは、水がなく、水なしの泥だまりがない場合は当てはまりません。

3.5。 異なるセクションが同じことを言うのはなぜですか？

実際、TKには、他のサブセクションの内容をほぼ繰り返すサブセクションがあります。たとえば、組織のサポート、要員の数と資格の要件があります。両方の段落で、スタッフについて話します。しかし、最初のケースでは、組織構造に関する情報を提供します。部門とは何か、他の部門との相互作用を確立する方法です。同意します。これは、単に人員の数と資格の要件とまったく同じではありません。



ただし、小規模なシステムの場合、必要な管理者は1人または2人で、モデレーターは数人です。この場合、2つのセクション全体で説明することは何もありません。次に、一部のセクションを省略し、他のセクションでは、要件の完全なステートメントを提供します。

3.6。 TKを質の高い方法で発行する必要がありますか？

TKの設計の要件はGOST 34.602-89のパラグラフ3に記載されていますが、この点について少し説明しましょう。



もちろん、メインコンテンツ。しかし、第一に、彼らは服で迎えられ、第二に、スキップするフォントで文字が読めないテキストを読むことは困難です。読者は質の低いデザインに気を取られ、コンテンツを掘り下げることはより困難になります。したがって、厳密な技術内容と限られた用語は、カラフルな表現のない技術文書で受け入れられます。読者は芸術的なターンではなく、本質に焦点を合わせるべきです。



TKのような大きなドキュメントの実行に関するいくつかの提案があります。



まず、大きなドキュメントでスタイルを使用することが不可欠です。段落内の下線または強調表示を除き、1つのフラグメントのみのフォントと段落の設定を変更しないでください。変更すると、スタイルが変わります。



第二に、オートコンプリートの目次、用語と略語のリスト（まあ、これまたはその略語の意味を推測する喜びはありません）、タイトルページなどの必須要素を忘れてはなりません。また、ドキュメントのバージョンのリスト、変更のリストを提供することをお勧めします。特定のバージョンが送信された日付を後で追跡するのは非常に簡単です。



第四、個々の要件は個別の番号付き段落に記載する必要があります。 1つのフラグメントに2〜3の要件がある場合、最初のフラグメントのみが読み取られ、脳は残りを逃します。 TKは、各段落の前で、要件が満たされているかどうかを確認できるドキュメントです。



5番目に、リンクの配置を軽視しないでください。ある機能または要件が言及されている段落を読んで、理解できない場合があります。これは同じドキュメントまたは別のドキュメントからのものです。これからなら、どのセクションで。したがって、現在のテキストで言及されている場合は、他のセクションを参照してください。当然、リンクは自動でなければなりません。



厳密な規則に従って、作業指示書はフレームなしで作成されますが（これは段落3に記載されています）、残りのドキュメントはフレーム化されています。これは、GOST 24.301-80「ACSの技術文書システム」で確立されています。テキスト文書の実装に関する一般的な要件（修正番号1、2として）。この標準は、TKおよび設計前の段階で作成されたドキュメントを除く、すべてのドキュメントの実行に関するルールを確立します。私は個人的にどの文書のフレームも好きではありませんが。

4.セクション1.「一般情報」/ p。2.3 GOST 34.602-89 /

このセクションで提示される情報のほとんどはコメントを必要としないため、一部のサブセクションのみに焦点を当てます。



したがって、「システムの作成に基づく文書のリスト」とは、法律、命令、または合意を意味します。また、そのようなドキュメントは、サブシステム用にTKを開発する場合、別のTKである可能性があります。一般に、ToRにはドキュメントのリストを含むいくつかのセクションがあり、技術的なタスクのこれらの部分の目的の違いを非常に明確に理解する必要があります。



サブセクション「システム（部品）の作成、個々のツール（ハードウェア、ソフトウェア、情報）およびソフトウェアとハ​​ードウェア（ソフトウェアおよび方法論）システム複合体の製造および試運転に関する作業の結果を処理して顧客に提示する手順」では、作業の受け入れに関する一般情報を提供します。たとえば、ドキュメントを転送し、一連のシステムテストを実施するという事実。ここでは、作業結果を転送する手順についてのみ説明します。以下では、他のセクションでこのトピックを詳細に開示します。

5.セクション2.「システムの作成（開発）の目的と目標」/ p。2.4 GOST 34.602-89 /

ここで、システムを作成する目的と目的の違いを理解する必要があります。多くの場合、これらの概念は混同されています。たとえば、システムの目的は個人アカウントの自動化であり、目標は個人アカウントを作成することであると書いています。オイルはオイルです。場合によっては、これらの概念は実際に一致しており、予約のみを記述します。



その目的のために、すべてが明確になっています。自動化されたアクティビティのタイプを正確に示します。たとえば、生産会計用のシステムを作成する場合、自動化されたタイプの会計、自動化されたオペレーション、および自動化が想定されるオブジェクトを引用する価値があります。



目標では、すべてが異なります。目標は、プロジェクトの計画対象です。それをビジネス目標と呼ぶことができます。自動化プロジェクトの次の可能な目標を強調します。

1. ( , ..)
2. (, -, , ).
3. ( , , ).
4. : , .
5. , . , , «», .

また、GOSTは、目標の達成を評価するための基準、つまり特定の指標を提供する必要があるとも述べています。たとえば、3人で1日に合計20件の注文を収集しています。また、システムの実装後、全員に20の注文、つまり3倍の注文を収集してもらいます。そのような指標がそこで知られている場合、この段落でそれらを示します。

6.セクション3.「オートメーションオブジェクトの特性」/ p。2.5 GOST 34.602-89 /

非常に重要で、多くの場合、正式に記述されたセクション。私の意見では、これはTKの最も重要なセクションですが、それなしでは、システムが何について作成されているのかがわかりません。



まず、「自動化オブジェクト」とは何かを定義しましょう。倉庫や工場、経理部門を自動化すれば、すべてが明確になります。また、たとえば、新しいソーシャルネットワークを作成した場合、オブジェクトは存在していません。しかし、実際には、オブジェクトは自動化されたプロセスを意味する可能性が高くなります。倉庫の場合でも、倉庫自体を自動化することはありません（箱の保管をどのように自動化できますか？）、しかし倉庫は処理します。



このセクションを正式に実行すると、システムの目的の説明と非常に似たものになり、TORに別のウォーターレイクが表示されますが、システムが何をすべきかは明確ではありません。



このセクションには以下を含める必要があります。

1. 顧客の説明：顧客の活動、支店の数、従業員。もちろん、作成中のシステムに直接関係する部分の顧客を特徴付ける必要があります。
2. システムユーザーに関する情報：ユーザーの種類、さまざまなユーザーに対してシステムが果たす役割。
3. 自動オブジェクトの説明。たとえば、倉庫を自動化する場合、倉庫の面積、通路の数、通路の幅、ラック、個別の組み立てエリアがあるかどうか、作業する人の数、責任を説明する必要があります。それから、倉庫プロセスがどのように見えるべきか、使用されている機器が何であるかを具体的に自動化していることを理解します。
4. 自動化プロセスの説明。もちろん、TKでプロセスを詳細に記述する必要はありません。ただし、一般的なシナリオが必要です。そうして初めて、どの機能が利用可能になるべきかが明らかになります。
5. 自動化オブジェクトの詳細な説明を提供するドキュメントのリスト。

このセクションの説明がTKの開発の半分以上を費やした場合があります。さまざまな情報を収集し、分析し、慎重に説明するのに長い時間をかけて細心の注意を払っています。

7.セクション4「システム要件」

GOST 34によるTKには、1つの巨大なセクションがあります：セクション4「システム要件」。次の3つのサブセクションがあります。

• システム全体の要件。
• システムによって実行される機能（タスク）の要件。
• 担保の種類の要件。

これらのサブセクションは個別に検討します。

7.1。サブセクション4.1。「システム全体の要件」/ p。2.6.1 GOST 34.602-89 /

サブセクション4.1「システム全体の要件」では、さまざまな角度から作成されるシステムを説明する、いわゆる非機能的で一般的な要件が説明されています。



ところで、すでに述べたように、サブセクションを追加および省略できます。したがって、ここに記載されている番号はおおよそのものであり、記事内の向きに役立ちます。

7.1.1。条項4.1.1。「システムの構造と機能の要件」/ p。2.6.1.1 GOST 34.602-89 /

この項目は非常に広範囲であり、システムのアーキテクチャの一般的な概念を提供する必要があります。これらの要件をより詳細に分析します。



1.サブシステムのリスト、その目的と主な特性、階層レベルの数の要件、およびシステムの集中化の程度。



この段落では、私は通常引用します：

• ( , , , -, , , ) , ( , SMTP, SMS-, -, -, , , ..);
• .

マイクロサービスアーキテクチャを計画している場合は、サービスの機能をリストして説明することは理にかなっています。



わかりやすくするために、以下の例に示すように、システムの構造図にその部品と関連システムを指定して添付することが望ましいです。







...または：







2.通信方法の要件およびシステムコンポーネント間の情報交換の手段。



3.作成されたシステムと関連システムとの関係の特性の要件、情報の交換方法に関する指示を含むその互換性の要件（自動的に、文書の送信、電話などによる）



現代の状況では、ほとんどの対話はHTTP（S）プロトコルを使用して実行されます。これ以外に、書くことは何もないようです。ただし、これらのアイテムは非常に大きくなる可能性があるため、アプリケーションに送信されます。次の情報を提供する必要があります。

• 特定のシステムと統合する理由を一般的に理解するための、送信された情報のリスト、少なくとも一般的な説明。
• プロトコルの説明（または説明リンク）、特にデバイス接続の場合。
• ローカルネットワーク構造。
• 必要なデータレート。
• モバイルインターネットまたはWiFiの使用。
• 自動化されていないデータ送信方法の説明。

4.システムの動作モードの要件。

動作モードにはいくつかの分類があります。

• : , , (, , , API, );
• : , , , ;
• : 24/7 ( );
• : ;
• : , , ( );
• : -, , (, , );
• : ( ), , (, , , );
• : , « »;
• アプリの可視性：ダイアログまたは背景
• システムへの影響の可能性：通常、トレーニング、テストモード。

5.システムを診断するための要件。



マイクロサービス（スペース）アーキテクチャに基づくシステム、機器を含むシステム、センサー、制御システム、端末などに対して、継続的または定期的な診断の要件を作成する必要があります。もちろん、単一のサーバーで実行されるソフトウェアのみが開発されている場合、これらの要件は不要です。そのため、何かが機能しなくなるかどうかがわかります。



6.システムの開発、近代化の見通し。



「システムの構造と機能の要件」のサブセクションのシステム開発の見通しはどうですか？しかし、今、100人用のアルファ版を作成していて、1年で世界中のさまざまな地域で100万人以上のユーザーを同時に利用したいと考えています。次に、作成の段階で、すぐにクラスターアーキテクチャを提供する必要があります。



または、現在は1つの組織で働いており、6か月後にはそれらのいくつかが存在することになります。つまり、拡張の可能性を予測する必要があるということです。



つまり、このセクションでは、近代化のすべての見通しを書き留めることができますが、特にアーキテクチャに確実に影響する見通しに注意してください。

7.1.2。条項4.1.2。「要員の数と資格の要件」/ p。2.6.1.2 GOST 34.602-89 /

前述したように、自動化されたシステムは「人員とその活動のための自動化ツールのセット」で構成されています。したがって、要員の要件と資格はTORに示されています。



特定の生産ラインを自動化する場合、スタッフの数がわかります。しかし、多くの場合、実行される作業量に依存します。したがって、役職、勤務スケジュール、アクティビティの説明（アクセス権の割り当て用）、およびおおよその資格を示してください。少なくとも、システム管理者とオペレーター（多くの場合、モデレーター）が必要です。アクセスのレベルが異なるいくつかのタイプのオペレーターを用意する必要がある場合があります。



従業員の要件が顧客によって設定されることが多いのは明らかです。しかし、第一に、技術仕様が両当事者のために作成され、第二に、請負業者が保護されることを既に述べました：スタッフの選択条件が満たされない場合、システムが実装されていない場合、顧客は何を望みますか？

7.1.3。条項4.1.3。「パフォーマンス指標の要件」/ p。2.6.1.3 GOST 34.602-89 /

このサブセクションでは、可能性のあるインジケータのリストがGOSTテキストにないため、好きなものが書かれていることが多く、オープンソースで見つけることはほとんど不可能です。GOSTで与えられる「適応性の程度」、「近代化の限界」、および「確率時間特性」は、最初にACS（自動制御システム）で示され、次に測定がかなり難しいことに注意してください。したがって、これらの特性は必ずしも適切ではありません。



それにもかかわらず、テキスト自体では、「予定の指標」は「システムの目的への適合の程度を特徴付けるパラメーター」として定義されています。現代のコンピューターシステムでは、このシステムを特徴付ける定量的な値は、主にパフォーマンスとデータストレージボリュームに関連しています。



宛先インジケータは次のとおりです。

• システムで同時に作業しているユーザーの数。
• サーバーに対して同時に実行されたリクエストの数。
• トランザクションの単位時間あたりの（記録された）トランザクションの数。
• 異なる数のワンタイムリクエストと作業ユーザー、異なる量の処理済みデータ（特にレポートの検索と集計時）の応答時間。
• 保存されるデータの量（特に、画像とビデオ）;
• 最大負荷に達したときの追加の計算能力の接続時間。
• 保存容量の大幅な増加を伴う追加容量の接続時間。

これらのすべての特性は、サーバーハードウェア、アプリケーションサーバーとDBMSアーキテクチャ、リレーショナルまたは非リレーショナルDBMS、マイクロサービスなどの選択に影響します。

7.1.4。条項4.1.4。「信頼性の要件」/ p。2.6.1.4 GOST 34.602-89 /

GOSTのテキストは、信頼性の要件で何を示す必要があるかを十分に詳しく説明しています。それでも、この規格に固有の信頼性を確保するためのアプローチを理解するには、27シリーズのGOSTを学習する必要があります。まず、用語に精通する必要があります。これは、信頼性の概念、測定方法、および提供方法を​​理解するのに十分です。したがって、GOST 27.002-89を参照してください。 「技術の信頼性。基本的な概念。用語と定義。」



自動化システムに適用できる基本概念は可用性係数です：99％、99.9％、99.99％。 「9」の各数は、特定の手段によって提供されます。



これらの要件はどのような技術的解決策に影響しますか？これは予備容量の数（それらは異なります）、地上の技術要員の可用性、無停電電源装置だけでなくディーゼル発電機の使用、および2つの独立したソースからの接続（信頼性カテゴリIまたはIIによる電力グリッドへの接続）です。

7.1.5。条項4.1.5。「セキュリティ要件」/ p。2.6.1.5 GOST 34.602-89 /

このサブセクションでは、機器の取り扱い（設置、試運転、操作）の安全要件について説明します。現在、これらの要件は労働保護と呼ばれ、第12シリーズのGOST（SSBT-労働安全基準のシステム）に含まれています。TKでは、誰かがセキュリティに真剣に取り組むつもりであれば、これらのセクションのリストを提供するだけで十分です。

7.1.6。条項4.1.6。「人間工学と技術美学の要件」/ p。2.6.1.6 GOST 34.602-89 /

GOSTの要件は次のとおりです。「人間工学と技術美学の要件には、人間の機械とのやり取りに必要な品質とスタッフの作業環境の快適さを指定するACインジケーターが含まれます。」



通常、この段落には、システムには便利で美しいインターフェースが必要であると書かれています。しかし、利便性と美しさを測定する方法は？そのため、この要件を省略するか、インターフェースが後で開発される設計プロジェクトに対応すると言うか、モバイルアプリケーションを開発するためのいわゆる「ガイドライン」などの標準を提供します：AndroidのマテリアルデザインとiOSのヒューマンインターフェースガイドライン。



また、当社にとって特に重要な特定の機能を実装する際の遷移（クリック）の最大数、データ検索の平均速度などを指定することもできます。

7.1.7。条項4.1.7。「モバイルスピーカーの輸送要件」/ p。2.6.1.7 GOST 34.602-89 /

時代遅れの要件をいくつか言います。今では、以前の大型コンピューターのトラック上のサーバーは持ち運びできません。それでも、ある種のスーパープロテクション、DMZの背後にある内部回路、そしてラップトップを介したリモートワークの必要性があると想像してください。はい、VPNはいつでも構成されますが、管理ガイドに反映され、ネットワーク構成によって可能性自体が提供されている場合はより適切です。

7.1.8。条項4.1.8。「操作、保守、修理、および保管の要件」/ p。2.6.1.8 GOST 34.602-89 /

これらの要件は、複雑な技術的手段（サーバー、ファイアウォール、スイッチ、ワークステーションなど）のメンテナンスに関連しています。機器に特別なメンテナンスが必要な場合は、このセクションで説明する必要があります。たとえば、月に1回較正する必要がある特別なデバイスがあるとします。

7.1.9。条項4.1.9。「不正アクセスから情報を保護するための要件」/ p。2.6.1.9 GOST 34.602-89 /

情報を不正アクセスから保護するというトピックは非常に広範囲であり、それを保証する手段も同様です。もちろん、Webサイトの個人アカウントおよびこのWebサイトの管理パネルへのアクセスについて話している場合、承認、パスワードの複雑さ、ロールアクセスモデルには十分な要件があります。ただし、金融システムまたは州のニーズに対応するシステムが作成されると、特別な要件が表示されます。



このサブセクションでは、システムの開発中に適用する必要がある対策だけでなく、その操作も示していることに注意することが重要です。



そのため、金融システムでは、Payment Card Industry Data Security Standard（PCI DSS）を使用する必要があります。個人データが保存されているシステムの場合-2012年11月1日付けのロシア連邦政府令1119「個人データ情報システムでの処理中の個人データの保護要件の承認について」。あなたのサブジェクトエリアには他の標準があるかもしれません。



一般に、保護装置は次のタイプに分類できます。

1. 作成されたソフトウェア製品によって提供される手段。
2. システム管理者が提供する対策。
3. 物理的保護対策。
4. 一般的な組織的措置。
5. ソフトウェア開発プロセス中に取られた対策。

1.作成されたソフトウェア製品によって提供されるセキュリティ対策：

• , .
• .
• .
• , , (DMZ).
• .

2. , :

• ().
• .
• (DMZ).
• : , .
• .
• : , .
• , .
• (, VPN).
• , .
• .
• , , . .
• .
• ( , ).
• .
• , .

3. :

• .
• .
• .

4. :

• .
• , .
• .
• , .
• .
• - , .

5. , :

• , ( , , , ..)
• .
• -.
• .
• .

7.1.10。4.1.10。節 「事故発生時の情報の安全性に関する要件」/ p。2.6.1.10 GOST 34.602-89 /

このセクションでは、情報の安全性を確保する必要がある可能性のある事故と障害のリストを提供します。そのようなイベントには以下が含まれます。

• 栄養の損失;
• サーバー障害;
• ストレージデバイス（ハードディスク）の障害。

7.1.11。4.1.11。節 「外部の影響の影響に対する保護の要件」/ p。2.6.1.11 GOST 34.602-89 /

このセクションは、冷蔵倉庫のサーバー、ワークステーション、およびその他の機器の場合、または逆に、高温の工業施設、ほこりの多い場所、または湿度の高い場所で役立ちます。また、振動、放射、またはその他の影響を考慮する価値がある場合もあります。

7.1.12。サブセクション4.1.12。「特許純度の要件」/ p。2.6.1.12 GOST 34.602-89 /

あなたが他の国（または私たちの国）で特許を取得した技術を使用すると思われ、特許権者がシステムの所有者に対して訴訟を起こす場合、この段落はあなたがチェックしたい国のリストを示します特許純度のため。

7.1.13。4.1.13節。「標準化と統一の要件」/ p。2.6.1.13 GOST 34.602-89 /

この項目は、ソフトウェアに関する参照条件に含まれることもめったにありません。特定の技術を使用するための要件と、文書および分類子の標準化された形式の両方を示しています。



この説明は、使用するフレームワーク、プラグイン、プロトコル、デバイス、数学アルゴリズム、サードパーティソフトウェアなどに特定の要件がある場合に特に重要です。これらのツールを使用する部分と目的を示すことを忘れないでください。



また、一部のクラスのシステムでは、特定のデータ交換プロトコルを使用することが習慣的である場合があります。たとえば、OCG標準は地理情報システム間でデータを交換するために使用され、OCPPは電気自動車の充電ステーションを制御するために使用されます。

7.1.14。4.1.14節。「追加要件」/ p。2.6.1.14 GOST 34.602-89 /

この段落は、GOSTのテキストに記載されています。彼はコメントを必要としません。

7.2。サブセクション4.2。「システムが実行する機能（タスク）の要件」/ p。2.6.2 GOST 34.602-89 /

このセクションは、最新のコンピューターシステムの中心です。実際には、システムは特定の機能を実行するために作成されます。多くの場合、外国の標準に基づいて作成され、通常は標準のないTKには、このセクションのみが含まれます。

7.2.1。機能説明の構造

最初に、システムの機能要件の構造を検討します。サブシステム-機能セット-機能-タスク。タスクは機能の一部であり、タスクは別の機能として説明できます。たとえば、ログイン機能の場合、タスクの1つとしてパスワードを導入します。また、パスワード入力手順を別の機能として説明できます。正確性の確認、パスワードの回復、プロンプトの表示などです。複合体は、機能を組み合わせたものです。たとえば、「基本情報の会計」、「オークションの開催」など。コンプレックスには2つ以上の機能があります。



システムが複数のサブシステムで構成されている場合、基本的にTKはサブシステムの機能のリストを提供し、サブシステムの個々のTKでサブシステムの機能要件を詳細に説明する必要があります（これらは多くの場合、CTZと呼ばれます-プライベートテクニカルタスク）。

7.2.2。実装に関する機能の種類

実際、すべての機能（またはそのタスク。1つの機能に複数のタスクが同時に存在する場合があります）は、次のタイプに分類できます。

• 情報を入力します。「会計情報」とも呼ばれます。
• 情報出力。
• 情報の自動処理。

7.2.3。役割に関する機能の種類

関数は、一般的なものと特別なものがあります。たとえば、一般的な機能には、オブジェクトのリストの操作、オブジェクトカードの操作、インタラクティブマップの操作が含まれます。これらの機能は、すべての特別機能または特別機能の一部に適用できます。

7.2.4。 スクリプトではなく要件

ToRには、システムとその作成プロセスの要件が含まれていることを忘れないでください。 スクリプトではありません。 TKは、システムが何をすべきかという質問に答えます。 技術設計がどのように答えるかという質問に。 技術的な実装を詳細に説明し始めたら、詳細に突入し、要件の完全なリストを提供するのに失敗します。私たちの脳は、広い範囲と詳細の検討のモードで同時に機能することはできません。



TORの機能の構造と技術設計は非常に異なる場合があります。1つのシナリオでは、いくつかの機能を実装でき、その逆も可能です。

7.2.5。 機能要件

関数の説明を作成する方法に関する推奨事項を次に示します。

1. 通常、機能とタスクの要件はアプリケーションに対して行う必要があります。 したがって、ドキュメントは非機能部分と機能部分に有機的に分割されます。 また、アプリケーションはいつでも個別に印刷および表示できます。
2. 大きな段落を避けてください。 何よりも、要件がパラグラフとサブパラグラフに分割されている場合：それらを認識し、実装を監視するのが簡単です（チェックボックスをオンにします）。 要件または情報のリストが提供されている場合は、番号付きリストまたは箇条書きリストで提供してください。
3. 名前から目的が明らかでない関数については、目的と解決すべき問題を示す必要があります。 そうしないと、TKコンパイラーでさえ、この機能またはその機能を説明した理由を忘れる危険があります。

7.2.6。 機能説明例

5.6。 システムへの車両の登録

次の要件が提示されます。



1）システムは、次の一般情報を許可する必要があります。

• 州登録マーク（GRNZ）;
• 所有者の名前。
• 所有者の住所。
• 車両データ収集サービスからのデータ（3.3、付録Bを参照）;
• 注。

2）システムは、運賃支払いに関連する以下の情報を考慮に入れる必要があります（指定された情報は本質的に情報であり、車両の登録カードで直接変更する可能性は不要です）。

• 現在の車両クラス（3.3の付録Aを参照）;
• 現在の料金（5.1、付録Aを参照）;
• 現在の契約（5.5項付録Aを参照）。
• カザフスタン共和国内務省からの情報に基づく車両クラス;
• 個人アカウントとその状態に関する情報（3.6の付録Aを参照）。
• 割引料金で車両レジストリに登録することに関する情報（3.5の付録Aを参照）。

3）システムは、以下の方法で車両に関する情報を登録および変更できるようにする必要があります。

• オペレーターが手動で;
• RFIDタグ登録システムから情報を受信すると（1.1、付録Bを参照）。
• GRNZカメラを使用して車両を識別する場合。

4）システムに新しい車両を登録するとき、システムは車両に関するデータを受信するためにサービスから車両に関するデータを要求する必要があります（3.3項、付録Bを参照）。 個々の車両の指定された情報を更新できる必要があります。

7.3。 サブセクション4.3。 「セキュリティの種類の要件」/ p。 2.6.3 GOST 34.602-89 /

一般に、GOSTによるTKの過剰量の例として、サポートの種類に関する要件のセクションがよく引用されます。 すべてのセクションとサブセクションを指定するかどうかについては、ほとんどの場合、書くことは何もありません。



実際、これは非常に重要なサブセクションですが、誰もがその目的を理解しているわけではありません。 開発または試運転を実装することが不可能な条件を説明しています。 これらの条件は「担保」と呼ばれます。



このサブセクションを読むとき、標準の起草者が「ソフトウェア」、「言語ソフトウェア」、「情報ソフトウェア」などによって意味するものが疑問に思う。 これらの用語はすべて解読されているGOST 34.003-90で回答を探す必要があります。

7.3.1。 4.3.1項「ソフトウェア」/ p。 2.6.3.1 GOST 34.602-89 /

最適なルートの自動計算を実装するシステムを作成する必要がある状況を想像してください。 「ルートの計算」ボタンはシンプルに見えるかもしれませんが、非常に複雑な数学的アルゴリズムと計算がその背後にある場合があります。 このようなアルゴリズムの開発に取り組む価値がないことは明らかであり、専門の数学者がこれに取り組んでいます。 そのようなアルゴリズムが利用可能な場合、それらの開発または既製のアルゴリズムの使用の要件も記述されます。

7.3.2。 4.3.2項「情報サポート」/ p。 2.6.3.2 GOST 34.602-89 /

GOSTのテキストでこの要件の説明を読むと、これは他のセクションで既に述べられていることの繰り返しであると思われます。 たとえば、「システム内のデータを編成するための構成、構造、方法」および「システムコンポーネント間の情報交換」の要件を再度説明するのはなぜですか？ しかし、システムの下でのGOSTのコンパイラには、ソフトウェアだけでなく、組織的手段のセット全体が含まれていたことを忘れています。



紹介する際に、顧客がシステムにデータを入力するオペレーターを提供しておらず、同時にシステムが機能しないと述べている状況に遭遇します。 おなじみの状況？ ただし、この入力を提供する要件が作業指示書に記載されている場合、この時点で顧客を直接突き止めることができます。 または、仕事のために特定の住所分類子にアクセスする必要がありますが、顧客からは提供されません。



したがって、この段落では、着信情報およびシステムのコンポーネントから非自動化された方法で送信される情報の要件を指定することは理にかなっています。 自動情報処理、DBMSの使用、システム内の情報交換については、他のセクションで詳しく説明します。

7.3.3。 4.3.3項「言語サポート」/ p。 2.6.3.3 GOST 34.602-89 /

この段落では次を提供します。

• プログラミング言語の使用要件（特定の設定がある場合）;
• インターフェース言語（どの言語、多言語インターフェース）;
• プロジェクトチーム間のコミュニケーションのための言語、翻訳要件。
• データ入出力の他の機能（利用可能な場合）：暗号化、システムとのユーザー対話の非標準的な方法。

7.3.4。 4.3.4項「ソフトウェア」/ p。 2.6.3.4 GOST 34.602-89 /

ToRの開発段階で特定された場合、このパラグラフは購入したソフトウェアのリストを提供します。

7.3.5。 4.3.5項「テクニカルサポート」/ p。 2.6.3.5 GOST 34.602-89 /

情報システムは、ハードウェア、サーバー、ネットワークなどがなければ機能しません。 機器の特定の特性を決定することは通常、技術設計に含めることをお勧めしますが、おおよその構成を作業明細書に記載して、顧客が将来のコストを把握できるようにすることができます。

7.3.6。 4.3.6節「メトロロジカルサポート」/ p。 2.6.3.6 GOST 34.602-89 /

システム内のセンサーからデータを受信する予定の場合、使用する測定器、測定器が提供する精度、これらのツールを認証する必要があるかどうかを理解する必要があります。

7.3.7。 4.3.7項「組織のサポート」/ p。 2.6.3.7 GOST 34.602-89 /

システムをゼロから作成していると想像してください。 たとえば、これは新しい物流施設の倉庫管理システムです。 つまり、壁しかありません。 または、システムをアップグレードし、変更を実装するには、組織構造を変更する必要があります。 そのような場合、提供されたシステムが実際に動作するプロセスの編成に関する条件を指定する必要があります。

7.3.8。 4.3.8節「方法論的サポート」/ p。 2.6.3.8 GOST 34.602-89 /

システムを管理するには、特別な能力を持つ人員が必要になる場合があります。 この場合、TORのメソッド、規範、および標準のリストを提供する必要があります。これらのリストを使用して、システムを操作する従業員を熟知する必要があります。

7.3.9。 他の種類の担保

新しいTKを開発するときは、試運転を成功させるために必要なものを検討する必要があります。 たとえば、使用される法的枠組みが完全に定義されておらず、その開発が実装に影響する可能性がある場合、法的サポートの要件を書き留めることがよくあります。 そのような問題は参照条件を起草する前に最もよく解決されますが 。

8.セクション5「システムの作成（開発）に関する作業の構成と内容」/ p。 2.7 GOST 34.602-89 /

このセクションは組織的であり、多くの場合契約に入れられます。 ただし、ToRのこの情報は指定できます。



実際、これは開発と実装のための短い計画です。 コンパイルするとき、通常、次の列のすべてまたは一部をリストする表を提供します。

• ステージ（サブステージ）の名前。
• 作業内容（短い説明、タスクのリスト）。
• 作業の結果（承認されたドキュメント、開発および提出されたソリューション）。
• 設計、作業、またはレポートのドキュメント。
• 責任者（この作業を実行するのは顧客、請負業者、または他の人）。 両当事者が共同で結果を出さなければならない場合、役割が示されます。
• 期間（日付、日付、タイミングの開始）。

このセクションの内容の例を以下の表に示します。

9.セクション6「システムの監視と承認の手順」/ p。 2.8 GOST 34.602-89 /

このセクションでは、顧客によるシステムの受け入れプロセスについて詳細に説明します。どのテストを実行する必要があるか、テストデータに何を含めるか、どのドキュメントをテストするか、コメントの作成方法および削除方法について説明します。

9.1。 サブセクション6.1。 「システムとそのコンポーネントの種類、構成、量、および試験方法」/ p。 2.8.1 GOST 34.602-89 /

通常、ここではテストのリストを示し、テスト方法はドキュメント「Test Program and Methodology」に記載されることに言及します。これは主要なテストケース、テストスクリプトの説明です。



テストの種類について説明します。 テストの種類、構成、ドキュメントの要件は、GOST 34.603-92「情報技術。 自動化システムのテストの種類。」 したがって、このセクションと技術プロジェクトを開発するときは、必ずこの標準を参照してください。ここでは、主なポイントのみを説明します。



テストとは何かを理解してみましょう。



1.テストは次のタイプに分類されます。

• 予備。
• 試運転。
• 受け入れ。

2.予備（および部分的に受け入れ）テストは、次のように分けられます。

• 自律（関連システムとの統合なし）。
• 統合（関連システムと連携）。

テストがさまざまな段階に分けられるのはなぜですか？ まず、GOST 34.603-92は内部受け入れと外部受け入れを区別しないため、テストの一部は顧客なしで実行できます。 第二に、順次テストプロセスが部分ごとに説明され、すべてが統合されます。



テストプロセスを簡単な言葉で説明してみましょう。



1.システムの一部の予備的な自律テスト。 複数のサブシステムまたは大きなモジュールが含まれている場合、システムの各部分は個別にテストされます。 通常、このようなテストは自律的に、つまり隣接システムと統合せずに実行されます。 システムが単純な場合、このステップは安全にスキップできます。



2.システム全体の予備的な自律テスト。 複合システム内のシステム全体が自律モードでテストされます。つまり、隣接システムと統合されません。 隣接システムに関連付けられている機能はテストされていません。 極端な場合、「スタブ」が置かれる（統合のエミュレーション）か、データベースに外部ソースからのデータが事前に入力されます。



3.予備的な包括的なテスト。 システムは統合モード、つまり隣接システムとの相互作用でテストされます。 このフォームでは、試運転のためにシステムが顧客に転送されます。



4.実験操作。 MAはさまざまなモードで実行できます。 最良の方法は、実際のユーザーと実際のタスクを使用して、実際のデータを活用することです。 このタイプのテストのみが、システムが実際に動作することを確認します。 試運転中に、欠点は取り除かれます。



5.受け入れテスト。 これが最後の種類のチェックです。 すべての欠点を取り除いた後の試運転が工業的にスムーズに進まないのはなぜですか？ そのため、通常は起こります。 しかし、高い叔父は、システムが実際に機能していることを「感じる」ために見なければなりません。 受入テストは、高額の手数料のために、それらを対象としています。 したがって、受け入れテストは、主に委員会のステータスにおいて予備テストと異なります。



また、この段落では、テスト方法が提供されるドキュメントが示されています。

• 予備テストと受け入れテストの場合、これは「予備（受け入れ）テストのプログラムと方法論」です。 文書を作成するためのガイダンスは、一度に2つの標準に含まれています。 簡単に-GOST 34.603-92（段落2.2.2および4.1）および詳細-RD 50-34.698-90「方法論的指示。 情報技術。 自動化システムの標準とガイドラインのセット。 自動化システム。 ドキュメントのコンテンツの要件。」
• 以下のためにパイロット操作内容項目である文書「試運転のプログラム」を、提供する。3.1 GOST 34.003から90を。また、「試行操作のジャーナル」（GOST 34.603-92の3.2項を参照）の使用も規定する必要があります。これには、欠点とその除去の結果が含まれます。

9.2。サブセクション6.2。「ステージごとの作業の受け入れに関する一般要件」/ p。2.8.2 GOST 34.602-89 /

このセクションでは、通常次のことを示します。

1. 誰の領土で、誰の機器で試験が行われるか：顧客または請負業者。
2. テストの実施方法の一般的な説明（たとえば、ドキュメントのチェック、ユーザーインターフェイス要素の存在、スクリプトの作成など）。
3. 参加者のリスト。
4. テスト結果を作成するドキュメントのリスト：
   
   
   
   
   • 予備テストおよび受け入れテストの場合、これはチェックとその結果のリストを提供するテストレポートです。
   • 試運転用-試運転ジャーナル。

10.セクション7「システムを運用するための自動化オブジェクトの準備に関する作業の構成と内容の要件」/ p。2.9 GOST 34.602-89 /

このセクションで説明するプロセスは、多くの場合実装と呼ばれます。これらの作業は、セクション5「システムの作成（開発）に関する作業の構成と内容」でも説明されています。しかし、セクション5でそれらは簡単に言及されているだけであり、詳細な説明はここで与えられます。



オブジェクトを準備するときは、原則として、次の作業を実行する必要があります。

1. 必要に応じて、再編成、新しいスタッフの募集。
2. スタッフのトレーニング。
3. Webアプリケーションの場合：サイトの一般的なセクションの開発とユーザー契約（個人データの処理に同意）。
4. リファレンスブックやその他の背景情報を入力します。
5. 古いシステムからデータを転送します。
6. 産業用サーバーにシステムを展開します。
7. 隣接システムとの統合を構成します。
8. アクセスシステムのセットアップとアカウントの作成。

これらのポイントのいくつかは、特にデータ転送とディレクトリへの記入に関して、詳細に説明する必要があります。

11.セクション8「ドキュメント要件」/ p。2.10 GOST 34.602-89 /

正式に文書を参照する価値はありません。ドキュメント-これはプロジェクト管理、プロジェクトワークフローです。すべてを頭の中に収めることはできません。プロジェクトの成功は、ドキュメントの入手可能性と品質に依存します。もちろん、「重量のため」のドキュメントがあり、それらはそれに応じて処理される必要がありますが、落ち着いた整然としたモードのドキュメントなしでは、プロジェクトは実行できません。



GOST 34に準拠した自動化プロジェクトの文書化は、次の標準によって規制されています。

• GOST 34.201-89自動システムを作成する際の文書の種類、完全性、および指定。
• RD 50-34.698-90ガイド​​ライン。情報技術。自動化システムの標準とガイドラインのセット。自動化システム。文書の内容に関する要件。
• 参照条件-GOST 34.602-89については、現在議論中です。

最初の標準（GOST 34.201-89）は、ドキュメントのリストと構造を提供します。2番目-RD 50-34.698-90-以下の文書の内容が示されています。

• 予備設計および技術プロジェクトのドキュメント。
• 設計前の段階で開発されたドキュメント。
• 組織および管理文書（行為、プロトコルなど）

11.1ドキュメント構造の機能

必要なドキュメントのリストを作成するとき、彼らは通常RD 50-34.698-90を見て、必要なドキュメントを選択します。同時に、ドキュメントはかなり複雑な構造をしているため、多くの間違いがあります。これについては、GOST 34.201-89で説明されています。



ドキュメントのリストを編集するのに役立ついくつかのルールを特定してみましょう。



1.各ステージには、独自のドキュメントセットがあります。



各ステージには独自のドキュメントセットがあります。これを理解することは非常に重要です。設計段階で運用文書の開発を規定する必要はなく、その逆も同様です。それは純粋に形式的な紙であり、かなりの時間を費やすことになります。また、システムの開発が終了するまで「ユーザーガイド」が作成されない場合、通常は誰も作成しません（このような図にも出会っていますが）、開発が完了すると、通常はプログラマー向けのスクリプトを含む「自動化された機能の説明」が作成されます。また、RD 50-34.698-90を読むと、一部のドキュメントが重複するコンテンツを持っているという印象を受けるかもしれません。これは、ドキュメントが異なる段階を対象としているという事実も原因です。



いくつかのドキュメントは1つまたは別の段階で作成できるため、GOST 34.201-89は繰り返しを避けるために、たとえば、技術設計段階と作業文書の両方の段階で発行できる文書のリストと、これらの各段階は個別に。したがって、いずれかの段階でドキュメントのリストをコンパイルするときは、標準のいくつかのセクションでドキュメントのリストを調べる必要があります。



混乱しないように、Excelスプレッドシートをコンパイルしました。フィルターを使用すると、特定のステージのドキュメントの完全なリストをすぐに表示できます。



2.ドキュメントはトピック（プロジェクトの一部）に分かれています。



GOST 34には、システム全体のソリューションと、組織、技術、数学、ソフトウェア、情報のサポートについて説明したドキュメントが含まれています（上記のサポートの種類について説明しました）。 RD 50-34.698-90では、これらのドキュメントはプロジェクトの一部（トピック）ごとに分類されて正確に示されています。ドキュメントの目的を判断するために、常にこれに注意を払う必要があります。



3.ドキュメントを結合できます。



GOST 34.201-89は、あるケースが別のドキュメントに含まれる場合を直接示します。これは、1つまたは2つのページで、退化したドキュメントが残らないようにするために行われます。何か説明する必要があるが、ボリュームが非常に小さい場合は、別のドキュメントにテキストを含めるのが最善です。ほとんどの場合、「技術設計に関する説明」などのドキュメントがあり、セクションを追加できます。



4.運用および設計の見積もりは個別に強調表示されます。



GOST 34.201-89のコンパイラーは、表の個別の列にあり、運用および設計の見積もりに属することが示されているドキュメントのリストを備えています。



設計見積もりには、建設および電気工事を管理する文書、見積もり、調達計画、図面、電気図が含まれます。



運用ドキュメントには、システムの使用とメンテナンスをガイドするドキュメントが含まれます。マニュアルと指示、資料とデータのリスト、運用中の違反に関する情報を含むドキュメントです。

11.2文書リストの設計の特徴

前述のように、セクション5「システムを作成（開発）するための作業の構成と内容」で作業の段階を説明するときに、ドキュメントのリストも提供されます。文書の二重リストは、単純な理由で提供されます。文書の名前を示すだけでは不十分です。その目的を説明し、簡単な要約を提供する必要があります（もちろん、「ユーザーガイド」では内容を示すことは意味がありません）。そうしないと、プロジェクト管理でこのドキュメントまたはそのドキュメントが持つ価値を判断できません。GOSTはゲストであり、各プロジェクトでドキュメントの内容と役割は異なる場合があります。さらに、リストにはGOST 34によって規制されていないドキュメントが含まれている可能性があります。これらのドキュメントは必ず明確にする必要があります。



ドキュメンテーションルールでは、通常、次の列を持つテーブルを提供します。

• ステージ。
• ドキュメントの名前。
• 注：ドキュメントの開発標準、目的、概要、および主な機能を示します。

11.3ドキュメントのリストの例

大規模なプロジェクトで複雑なシステムを実装するには、かなり多数のドキュメントのリストが必要になる場合があります。そのようなリストの例を下の表に示します。

12. 9 « » /. 2.11 34.602-89/

正式なセクションのようですが、非常に便利です。TKの開発中にいくつかの記事を読んだことを覚えている状況を想像してください。たとえば、何かを明確にしたり、決定を正当化するために、何らかの理由でそれを見つける必要があります。ただし、その名前や格納場所はまったく覚えていません。したがって、有用な資料を使用するときは、必ずリストに載せてください。そして、テキストにソースを示す脚注を入れました。



多くのソースがある場合は、次のようにサブセクションに分割する必要があります。

• 開発されたシステムの類似体（プロトタイプ）を説明する資料。
• システムの一般的なアイデアを説明する資料。多くの場合、これらのドキュメントは設計前の段階でコンパイルされ、「オートメーションオブジェクトの特性」セクションで通常参照されるのはまさにこれらのドキュメントです。
• プロジェクト開発資料：34シリーズの使用済みGOSTのリスト、プロジェクト管理の使用済み標準。
• メインプロセスの実装に関連する資料：自動化プロセスの実装に関するルールを確立する法律、規格、内部規制、および注文のリスト。
• 一般および情報セキュリティの要件を含む資料と標準。

おわりに

もちろん、GOST 34に準拠した参照条件の準備は、簡単で単純とは言えません。GOSTが悪いからではなく、GOSTを使用すると、プロジェクト全体を考えて、ささいなことをすべてペイントできます。しかし、よく書かれたTORはプロジェクトの成功の半分です。



何かを明確にしたり補足したりする必要があると思われる場合は、コメントを書いてください。必ず記事を変更してください。



著者による他の記事を読む：

• 情報システムの開発における設計前調査。
• 病院の建設の例に関するIP（情報システム）の成功した設計の秘密。
• 情報システムの設計に関する注意事項。