IEEE規格。 プロロゾワ N.O.、ナザロワ O.B.、ダブレトキリーワ L.Z.

メンテナンスは、ソフトウェア ライフ サイクルの主要な段階の 1 つとして常に認識されています。 70 年代半ばにはすでに、メンテナンスがソフトウェア ツールの開発と実装のコストの 50% 以上を占める段階であることが認識されていました。

企業の存続に必要な業務プロセスの継続性と企業情報の安全性は、サポートおよび保守段階の作業の有効性によって決まります。

複数のバージョンの長期使用と保守が必要な複雑なソフトウェア システムの場合、そのライフ サイクルを規制し、標準プロファイルとプログラム品質認証を形式化して適用することが緊急に必要です。

規制文書と規範文書を使用すると、ソフトウェアのライフサイクルがより明確になり、構造、内容、品質、コストの点で予測可能になります。 ドキュメント、情報の内容、わかりやすさによって、サポート ドキュメントの構成と品質が決まります。

ソフトウェアのライフサイクルの中で最も長く最も重要な段階であるソフトウェアのメンテナンスを正しく効率的に組織するには、最も多くの時間、労働力、物的リソースを必要とするソフトウェアのメンテナンスを行うために、国際的および国内的基準で定められた推奨事項を考慮する必要があります。この段階の最適な組織化のための規定を含む標準。

まず、さまざまな規格におけるサポート段階の解釈を分析する必要があります。

ソフトウェア メンテナンスは、IEEE ソフトウェア メンテナンス標準 (IEEE 1219) によって、障害の除去、製品のパフォーマンスおよび/またはその他の特性 (属性) の改善、または製品の使用に適合させるための、リリース後のソフトウェア製品の変更として定義されています。変更された環境で。 この規格がシステム運用前のメンテナンスの準備の問題にも取り組んでいることは興味深いことですが、構造的には、これは規格に含まれる対応する情報アプリケーションのレベルで行われます。

さらに、ライフ サイクル標準 12207 (IEEE、ISO/IEC、GOST R ISO/IEC) では、メンテナンスが主要なライフ サイクル プロセスの 1 つとして位置づけられています。 この規格では、運用中に発生する問題を解決したり、製品の特定の特性を改善する必要性を認識したりするために、コードとドキュメントの観点からソフトウェア製品を変更するプロセスとしてメンテナンスを説明しています。 課題は、製品の完全性を維持しながら製品を変更することです。

国際規格 ISO/IEC 14764 (ソフトウェア エンジニアリングの標準 – ソフトウェア メンテナンス) は、12207 標準と同じ用語でソフトウェア メンテナンスを定義し、計画の問題、規制、サポート業務など、システムを稼働させる前のメンテナンス活動の準備作業に重点を置いています。

変電所の運転開始後は、その性能を技術仕様に定められた要件のレベルに維持する必要があります。 このタスクには、ソフトウェアの不具合やエラーを排除することと、場合によっては機能を向上させることの両方が含まれます。 これらの作業を整理するには、規格に指定されている規定を参照する必要があります。

多くの情報源、特に IEEE 1216 標準では、調整、適応、改善という 3 つのカテゴリのメンテナンス作業が定義されています。 この分類は ISO/IEC 14764 で更新され、4 番目のコンポーネントが導入されました。

したがって、今日は 4 つのカテゴリーのサポートについて説明します。

1. 是正サポート ソフトウェア製品の実際のエラーを排除 (修正) する必要があるために生じる変更が含まれます。 ソフトウェア製品が定められた要件を満たしていない場合には、修正サポートが実行されます。

2. 適応型サポート これは、変化した環境 (条件) にソフトウェア製品を適応させる必要性に関連します。 これらの変更は、システム インターフェイス、システム自体、または技術的手段に対する新しい要件の実装に関連しています。

3. フルサポート ソフトウェアのパフォーマンス特性と保守性を向上させるための変更を決定します。 これらの変更により、ユーザーへの新しい機能の提供、付属ドキュメントを開発するためのテクノロジの改訂、またはドキュメント自体の変更が生じる可能性があります。

4. 予防サポート ソフトウェア製品の潜在的な (隠れた) エラーを排除 (修正) する必要によって引き起こされる変更を目的としています。 予防保守は通常、人命の確保または保護に関連するソフトウェア製品に対して実施されます。

保守性はソフトウェア品質の指標の 1 つであり、顧客、サプライヤー、ユーザーにとって重要な特性です。

ソフトウェア システムの保守性または保守性は、たとえば、IEEE 610.12-90 ソフトウェア エンジニアリング用語の標準用語集、Update 2002) によって、指定された要件を満たすための保守、拡張、適応、および調整の容易さとして定義されます。 ISO/IEC 9126-01 規格 (ソフトウェア エンジニアリング - 製品品質 - パート 1: 品質モデル、2001) では、保守性を品質特性の 1 つとして考慮しています。

保守性はソフトウェアの開発前に決定する必要があります。つまり、(ISO/IEC、#M12291 1200009075 GOST R ISO/ IEC) 12207#S。 開発者はサポート計画を作成します。この計画には、ソフトウェアの保守性、適切なリソース、作業を実行するためのアルゴリズムを確保するための具体的な方法が反映されている必要があります。

ソフトウェア ツールの品質は、ソフトウェア製品のメンテナンスの重要な側面です。 保守者は、ISO/IEC 9126 で定義されている 6 つの品質特性をカバーするソフトウェア品質保証プログラムを備えていなければなりません。ソフトウェア保守者は、ソフトウェアの特性を評価 (測定) するための方法論を定義、記述、選択、適用、および改善するための適切なプロセスを備えていなければなりません。 。

さらなるサポートのコストを削減するには、開発プロセス全体を通じて、保守性に影響を与える特性を指定、評価、制御する必要があります。 このような作業を定期的に実施すると、さらなるメンテナンスが容易になり、（品質特性としての）メンテナンス性が向上しますが、このような特性は開発中に無視されることが多いため、これを達成するのは非常に困難です。

前述したように、ソフトウェアのメンテナンスはライフサイクルの中でもコストがかかる段階であり、その作業を最適化するには、メンテナンスのコストを見積もるためのさまざまな方法を適用する必要があります。

サポート作業のコストは、さまざまな要因の影響を受けます。 ISO/IEC 14764 では、「メンテナンスのコストを見積もる最も一般的な方法は 2 つあります。それは、パラメトリック モデルと経験の使用です。」と述べています。 ほとんどの場合、これらのアプローチの両方を組み合わせて、評価の精度を向上させます。

さまざまなサポート グループのパフォーマンスを比較するために、サポート スタッフの生産性を内部的に評価するさまざまな方法があります。 保守組織は、関連する作業を評価する基準を決定する必要があります。 IEEE 1219 および ISO/IEC 9126-01 (ソフトウェア エンジニアリング - 製品品質 - パート 1: 品質モデル、2001) 標準は、特にメンテナンスの問題と関連プログラムに焦点を当てた特殊な指標を提供します。

メンテナンス作業は、プロセスの詳細なインプットとアウトプットを含めて厳密に規制され、記述される必要があります。 これらのプロセスは標準でカバーされています IEEE 1219 および ISO/IEC 14764。

メンテナンス プロセスは、ソフトウェアが稼働した瞬間から IEEE 1219 標準に従って開始され、メンテナンス活動の計画などの問題が関係します。

ISO/IEC 14764 規格は、メンテナンス プロセスに関連する 12207 ライフサイクル規格の規定を明確にしています。 この規格で説明されている保守作業は、グループ化が若干異なることを除いて、IEEE 1219 の作業と似ています。

GOST R ISO/IEC 14764-2002 規格からの抜粋を詳しく見てみましょう。この規格には、国際規格 ISO/IEC 14764 の完全な正文が含まれています。

ソフトウェア メンテナンス プロセスについて説明している GOST R ISO/IEC 14764-2002 に従って、サポート担当者が単一のプロセス内で行動できるように、ソフトウェア メンテナンス プロセスの詳細を文書化する必要があります。 品質指標 (メトリクス) のシステムは、メンテナンス プロセスの実装を容易にし、このソフトウェアの改善 (最新化) に貢献する必要があります。

保守者は (5.5.2.1 GOST R ISO/IEC 12207)、組織の問題、既存のシステム、および他のシステムとのインターフェース接続への影響について、問題報告または修正提案を分析するものとします。

分析に基づいて、保守者は変更を実装するためのオプションを開発する必要があります (5.5.2.3 GOST R ISO/IEC 12207)。 システムに変更を加える前に、保守者は契約に従って選択した変更オプションの承認を取得し、行われた変更が契約で定められた要件を満たしていることの確認を取得する必要があります (5.5.2.5 GOST R ISO/IEC 12207 を参照)。 .4.2 GOST R ISO/IEC 12207)。 保守者は、問題の報告または変更提案、分析の結果、および変更を実装するためのオプションを文書化する必要があります (5.5.2.4 GOST R ISO/IEC 12207)。

システムの移転を適切に制御するには、施設の移転計画を作成、文書化して実行する必要があります (5.5.5.2 GOST R ISO/IEC 12207)。 ユーザーは計画された作業に参加する必要があります。

サポート活動には、サポートを組織する際に考慮する必要がある独自の仕事や慣行が多数あります。 SWEBOK (Software Engineering Body of Knowledge) では、この種の独自の特性の例を次のように示しています。

放送：開発者からさらなるサポートを担当するグループ、サービス、または組織にソフトウェアを転送する、制御され調整された活動。

変更リクエストの承認/拒否 : 変更のリクエストは、受け入れられて作業に移されることも、必要な変更の量や複雑さ、それに必要な労力など、さまざまな正当な理由で拒否されることもあります。 優先順位、実現可能性の評価、リソースの不足 (実際に必要な場合に開発者を変更タスクの解決に関与させる能力の欠如を含む)、次のリリースでの実装の承認された計画に基づいて、適切な決定を下すこともできます。等

保守担当者への通知、修正依頼やバグレポートの状況の追跡手段 : リクエストまたは報告された問題に関連する変更の必要性、優先順位、およびコストを評価する取り組みを開始するエンド ユーザー サポート機能。

影響分析:既存のシステムに加えられた変更によって起こり得る影響の分析。

ソフトウェアサポート: ユーザーからの情報要求に応じて実行されるコンサルティング作業。たとえば、関連するビジネス ルール、検証、データ コンテンツ、特定のユーザーの質問、および問題の報告 (エラー、障害、予期せぬ動作、ユーザーとの作業面での誤解など)。システムなど);P.)。

契約と義務: これらには、従来のサービス レベル アグリーメント (SLA) や、サポート グループ/サービス/組織が関連する作業を実行する際のベースとなるその他の契約上の側面が含まれます。

さらに、メンテナンス プロセスをサポートする追加のアクティビティがあります。これは、SWEBOK では、ユーザーとの明示的な対話を含まないが、関連アクティビティを実行するために必要なメンテナンス スタッフのアクティビティと説明されています。 このような作業には、保守計画、構成管理、検証と認証、ソフトウェア品質評価、レビューのさまざまな側面、分析と評価、監査とユーザー トレーニングが含まれます。 このような特別な (内部) 作業には、サポート担当者のトレーニングも含まれます。

以下の表 1 は、情報システムの保守を組織する際に使用される主な標準の概要を示しています。

表 1. 情報システム保守分野の基準

上で説明した情報システムの保守プロセスを規定する国際標準および国内標準に加えて、国際標準を基礎とするさまざまな管理文書や企業内標準が存在します。 この場合、ソフトウェアの競争力を大きく左右するドキュメントの品質に特別な注意が払われます。 複雑なソフトウェア製品を作成し、そのライフサイクルを保証する場合、必要な標準を選択し、ドキュメントのセット全体、つまりすべての段階と保守作業の規制を保証するプロファイルを作成する必要があります。

具体的な例を用いて、情報システムを保守するための標準の適用について考えてみましょう。システムを高品質に機能させるには、障害やトラブルシューティングへの迅速な対応だけでなく、組織の変化するビジネス プロセスに継続的に適応する必要があります。 これに関連して、ZAO Firm SoftInCom の経営陣は、企業情報システム (CIS) の開発者である Orient Express とシステムの更新と保守に関する契約を結ぶ必要があると判断しました。

Eastern Express CIS のメンテナンスには、いくつかのタイプのサポートが含まれます (GOST R ISO IEC 14764-2002 に準拠)。 つまり、ソフトウェア製品の実際のエラーを排除 (修正) する必要によって生じる変更に関連する修正サポートです。 ソフトウェア製品が定められた要件を満たしていない場合には、修正サポートが実行されます。 ソフトウェア製品を最新化する適応性のある完全なサポートも提供します。

修正サポートの必要性は、ユーザーによって引き起こされたエラーだけでなく、システムエラーが発生したときにも発生します。 ユーザーによって引き起こされるエラーには、たとえば、重要なデータを誤って削除してしまうことが含まれます。これにより、システム バックアップの使用が必要になります。 新しいリリースは既存のデータ処理テクノロジに重大な変更が加えられ、新しいモジュールが組み込まれることを意味するため、特に新しいリリースのインストール後にシステム エラーが頻繁に発生します。

適応型サポートの必要性は、ビジネス プロセスの機能に変更があった場合 (プロモーションの実施、社外印刷フォームの変更、本社からの指示など)、または業務の実行が不便で変更が必要な場合に発生します。システムインターフェース内。

完全なサポートが提供される頻度は、他の種類のサポートよりもはるかに低くなります。 これは、CIS 設計者がシステムの機能を分析した後だけでなく、同様のインシデント、ユーザーの要望や要望が多数発生した場合に実行されます。

サポート作業は 4 つの段階に分けることができます。 欠陥と修正の分析、修正の実装、サポート結果の評価と受け入れ、別のプラットフォームへの移行。 これらの各段階には特定の入力と出力が含まれており、文書化する必要があります。

表 2 は、サポートの主な段階と、付属のドキュメントの段落の出力を示しています。

表 2. 情報システム保守プロセスの段階

GOST R ISO/IEC 12207 の 5.5.2.1 に従って、保守者は問題に関するユーザー レポートを分析する必要があります。 Orient Express CIS のユーザーからのリクエストの登録と記録を自動化するために、MantisBT インシデント登録システムが使用されます。 システムに登録されているデータをもとに MantisBT は、インシデント番号、作成日、カテゴリ、インシデントの本質、提案された解決策のフィールドを含む文書「ユーザーが特定した欠陥に関するレポート」を生成します。

分析に基づいて、保守者は変更を実装するためのオプションを開発する必要があります (5.5.2.3 GOST R ISO/IEC 12207)。 この目的のために、「CIS の新しい基本バージョンに対する準備および承認された調整のジャーナル」という文書が作成されており、次のデータが含まれています: カテゴリ、サポート組織によって特定された欠陥、CIS ユーザーによって特定された欠陥、調整。

次に、保守者は、行われた変更が契約で定められた要件を満たしていることの確認を取得する必要があります (5.5.4.2 GOST R ISO/IEC 12207)。 これらの目的のために、「CIS の新しいバージョンのリリースに関するユーザーへの通知」という文書が生成され、新しいリリースのインストールに対する同意の確認が求められます。

システムの転送を適切に制御するには、

ISO/IEC 12207 標準に準拠したソフトウェア ライフ サイクルの構造は、3 つのプロセス グループに基づいています (図 1)。

· ソフトウェアライフサイクルの主なプロセス (購入、納品、開発、運用、サポート)。

· 主要プロセス (文書化、構成管理、品質保証、検証、認証、評価、監査、問題解決) の実装を保証する補助プロセス。

· 組織プロセス (プロジェクト管理、プロジェクト インフラストラクチャの作成、ライフ サイクル自体の定義、評価と改善、トレーニング)。

米。 1. ソフトウェアのライフサイクル プロセス。

取得プロセス（取得プロセス）。 アクションで構成されています

ソフトウェアを購入する顧客のタスク。 このプロセスには次の手順が含まれます。

1) 買収の開始。

2) 入札提案書の作成。

3) 契約の準備と調整。

4) サプライヤーの活動の監督。

5) 作業の受領と完了。

納品までの流れ（供給プロセス）。 これには、顧客にソフトウェア製品またはサービスを提供するベンダーが実行する活動とタスクが含まれます。 このプロセスには次の手順が含まれます。

1) 配送の開始。

2) 入札提案に対する回答を準備する。

3) 契約書の作成。

4) 計画。

5) 実行と制御。

6) 検査と評価。

7) 納品と作業の完了。

開発プロセス（開発プロセス）。 これは、開発者が実行するアクションとタスクを規定し、設計および運用文書の準備、ソフトウェアの機能と適切な品質をテストするために必要な資料の準備など、指定された要件に従ってソフトウェアとそのコンポーネントの作成をカバーします。製品、研修要員の組織化に必要な資材など

開発プロセスには次の手順が含まれます。

1) システム要件の分析。

2) システムアーキテクチャの設計。

3) ソフトウェア要件の分析。

4) ソフトウェアアーキテクチャ設計。

5) 詳細なソフトウェア設計。

6) ソフトウェアのコーディングとテスト。

7) ソフトウェアの統合。

8) ソフトウェア認定テスト。

9) システム統合。

10) システムの認定試験。

11) ソフトウェアのインストール。

12) ソフトウェアの受け入れ。

運用プロセス（操作プロセス）。 ここでは、システムを運用する組織であるオペレーターの行動とタスクについて説明します。 このプロセスには次の手順が含まれます。

1) 動作テスト。

2) システムの運用。

3) ユーザーサポート。

メンテナンスプロセス(メンテナンスプロセス)。 これは、付随組織 (エスコートサービス) によって実行されるアクションとタスクを提供します。 このプロセスは、問題やソフトウェアの最新化や適応の必要性によってソフトウェア製品および関連ドキュメントの変更 (修正) が発生した場合にアクティブになります。 IEEE-90 標準に従って、メンテナンスとは、エラーを修正し、パフォーマンスを向上させ、または変化した動作条件に適応するために、ソフトウェアに変更を加えることを指します。

要件。 既存のソフトウェアに加えられた変更は違反してはなりません

その誠実さ。 メンテナンス プロセスには、ソフトウェアを別の環境に転送する (移行) ことが含まれ、ソフトウェアの廃止で終了します。

メンテナンス プロセスには次のアクションが含まれます。

1) 問題の分析とソフトウェアの修正要求。

2) ソフトウェアの修正。

3) 検査と受け入れ。

4) ソフトウェアを別の環境に移動する。

5) ソフトウェアの廃止。

補助プロセスのグループには次のものが含まれます。

ドキュメンテーション;

構成管理。 品質保証;

検証; 認証;

参加型評価;

問題の解決。

文書化プロセス（文書化プロセス）。 これは、ソフトウェアのライフサイクル中に作成される情報の形式的な説明を提供します。 文書化プロセスには次の手順が含まれます。

1) 設計と開発。

2) 文書の公開。

3) ドキュメントのサポート。

構成管理プロセス(構成管理プロセス)。 これには、システム内のソフトウェア コンポーネントのステータスの確認、ソフトウェアの変更の管理、ソフトウェア コンポーネントのステータスと変更の要求に関するレポートの説明と作成、完全性、互換性、正確性の確保を目的とした、ソフトウェア ライフ サイクル全体にわたる管理および技術的手順の使用が含まれます。ソフトウェアコンポーネントの保管と配信を管理します。 IEEE-90 標準によれば、ソフトウェア構成はその機能的および物理的特性の全体として理解されます。

技術文書で確立され、ソフトウェアに実装される特性。

構成管理を使用すると、ライフサイクルのすべての段階でソフトウェアへの変更を整理し、体系的に考慮し、制御することができます。 ソフトウェア構成管理の一般原則と推奨事項は、規格草案 ISO/I EC CD 12207-2: 1995「情報技術 - ソフトウェア ライフ サイクル プロセス、パート 2」に反映されています。

「ソフトウェアの構成管理」。構成管理プロセスには次のアクションが含まれます。

1) 構成の識別。

2) 構成制御。

3) 構成ステータスの説明。

4) 構成の評価。

5) リリース管理と配信。

品質保証プロセス（品質保証プロセス）。 これにより、ソフトウェアとそのライフサイクル プロセスが指定された要件と承認された計画に準拠していることが適切に保証されます。 ソフトウェアの品質は、指定された要件を満たすソフトウェアの能力を特徴付ける一連の特性として理解されます。 作成中のソフトウェアの信頼できる評価を得るには、ソフトウェア開発に直接関係する組織から独立して、その品質を保証するプロセスを実行する必要があります。 検証、検証、共同評価、監査、問題解決などの他のサポート プロセスの結果が使用される場合があります。 品質保証プロセスには次のアクティビティが含まれます。

1) 製品の品質を確保する。

2) プロセスの品質を保証する。

3) システム品質の他の指標を確保する。

検証プロセス(検証プロセス)。 これは、あるアクションの結果であるソフトウェア製品が、以前のアクションによって決定された要件または条件を完全に満たしているかどうかを判断することにあります（狭義の検証は、ソフトウェアの正しさの正式な証明を意味します）。

認証プロセス(検証プロセス)。 これには、指定された要件と、特定の機能目的を備えた作成されたシステムまたはソフトウェア製品の遵守の完全性を判断することが含まれます。 認証とは通常、ソフトウェア テストの信頼性の確認と評価を指します。

参加型評価プロセス(共同レビュープロセス)。 これは、プロジェクトの作業状況と、これらの作業 (アクション) の実行中に作成されたソフトウェアを評価することを目的としています。 これは主に、プロジェクトのリソース、人員、設備、ツールの計画と管理を制御することに重点を置いています。

監査プロセス(監査プロセス)。 これは、要件、計画、契約条件が遵守されているかどうかを判断することです。

問題解決プロセス(問題解​​決プロセス)。 これには、開発、運用、保守、その他のプロセス中に発見された問題 (検出された不一致を含む) の原因や発生源に関係なく、問題の分析と解決が含まれます。 検出された各問題を特定し、説明し、分析し、解決する必要があります。

ソフトウェア ライフ サイクルの組織プロセスのグループには、次のものが含まれます。

コントロール;

インフラの構築。

改善;

新しいバージョンのリリース。

教育。

管理プロセス（管理プロセス）。 これは、プロセスを管理する任意の当事者が実行できるアクティビティとタスクで構成されます。 この当事者（マネージャー）は、製品のリリース管理、プロジェクト管理、および取得、納品、開発、運用、保守などの関連プロセスのタスク管理を担当します。

インフラ構築プロセス(インフラストラクチャプロセス)。 これには、テクノロジー、標準、ツールの選択とサポート (保守)、開発に使用されるハードウェアとソフトウェアの選択とインストール、ソフトウェアの運用または保守が含まれます。 関連するプロセスの要件の変化に応じて、インフラストラクチャを変更および維持する必要があります。 インフラストラクチャも構成管理の対象の 1 つです。

改善プロセス（改善プロセス）。 ソフトウェアのライフサイクルプロセスの評価、測定、制御、改善を実現します。 ソフトウェア ライフ サイクル プロセスの改善は、使用するテクノロジー、管理方法、ツールの選択、トレーニングを改善することで、それに関わるすべての専門家の生産性を向上させることを目的としています。

人事。

学習過程(トレーニングプロセス)。 これには、初期トレーニングとその後の継続的なスタッフ開発が含まれます。

IT 分野では、最も実用的な標準が次の組織によって発行されています。

• 電気電子技術者協会(IEEE、www.ieee.org) は、ソフトウェア文書標準の作成など、長年にわたり科学および技術をリードする組織です。 ほとんどの標準は、経験豊富で責任ある専門エンジニアで構成されるさまざまな委員会によって開発されています。 IEEE 規格の一部は、ANSI (米国規格協会) 規格にもなっています。 主に IEEE 標準が、CP 用の MU の準備の基礎を形成しました。 Schmidt M. IEEE ソフトウェア エンジニアリング標準の実装。
• 国際標準化機構 (ISO)は世界中で、特に欧州連合（EU）と取引する生産者団体の間で絶大な影響力を持っています。 現在、ロシア連邦で翻訳および採用されているほぼすべての最新の IT 標準は、ISO が国際電気標準会議 (IEC) と共同で作成した標準です。 国際レベルで製品の品質を確保することに特別な注意が払われていることはご存知のとおり、1998 年 2 月 2 日のロシア政府令第 113 号に従って、ISO 9000 (品質管理を規制する一連の規格) の要件への準拠が定められています。企業では）政府命令を取得するための前提条件となります。
• ソフトウェア工学技術研究所(Software Engineering Institute - SEI、sei.cmu.edu - 1000 以上の記事) は、国防総省の請負業者のソフトウェア テクノロジーのレベルを向上させるために、米国国防総省によってカーネギー メロン大学に設立されました。 SEI の取り組みは、ソフトウェア開発プロセスの改善を戦略的な企業目標と考える多くの営利企業にも採用されています。 SEI が開発した標準の 1 つである Capability Maturity Model (CMM) を見ていきます。
• オブジェクト操作技術コンソーシアム(Object Management Group、www.omg.org) は、約 700 社の会員企業を擁する非営利団体です。 OMG は、分散オブジェクト指向コンピューティングの標準を定めています。 OMG では、プロジェクトを記述するための標準として統一モデリング言語 UML を使用していることに注意してください。 UML を詳しく勉強します。なぜなら... この言語を Rational の統合プロセスと組み合わせて使用​​することが、コース プロジェクトの中核を開発するための基礎となります。

システムのライフサイクルの概念

ソフトウェア開発の標準化の必要性は、標準の導入で最もよく説明されています。 GOST R ISO/IEC 12207-99「情報技術。 ソフトウェアのライフサイクルプロセス」: 「ソフトウェアは、情報技術や輸送、軍事、医療、金融などの従来のシステムに不可欠な部分です。 ソフトウェアの開発と管理には、さまざまな標準、手順、方法、ツール、およびオペレーティング環境の種類が存在します。 この多様性により、ソフトウェアの設計と管理、特にソフトウェア製品とサービスを組み合わせる場合に課題が生じます。 ソフトウェア開発戦略では、ソフトウェア開発者がソフトウェアの開発と管理の際に「同じ言語を話す」ことができるように、この多数から共通の順序に移行する必要があります。 この国際規格はその一般的な秩序を規定しています。」

標準 GOST R ISO/IEC 12207-99ソフトウェア システムの基本概念である「ライフ サイクル」を定義します (GOST R ISO/IEC TO 15271-2002「情報技術。GOST R ISO/IEC 12207 の適用に関するガイドライン」)。

GOST R ISO/IEC 12207-99では、システムの要件の確立から使用終了までのライフサイクルをカバーするプロセスからなる構造として、ライフ サイクル モデルの概念を導入しています。 この定義を修正し、次の 2 つの定義に分割することが提案されています。

1. ライフサイクル– 作業とタスクに分割された一連のプロセス。ソフトウェア製品の開発、運用、保守が含まれ、要件の確立から使用の停止までシステムの寿命をカバーします。
2. ライフサイクルモデル– ソフトウェア システムのライフサイクル全体を通じて実行されるプロセス、作業、タスクの順序、およびそれらの間の関係を決定する構造。

ライフサイクル プロセスは 3 つのグループに分類されます。メイン、補助、組織。

主要プロセスのグループには次のものが含まれます。取得、供給、開発、運用、サポート。 主要なライフ サイクル プロセスは、ソフトウェア ライフ サイクルに関与する主要な関係者の管理下で実装されます。 一次当事者は、ソフトウェア製品の開発、運用、保守を開始または実行する組織の 1 つです。 主な関係者は、顧客、サプライヤー、開発者、オペレーター、およびソフトウェア サポート担当者です。

図 - ISライフサイクルの主なプロセス

補助プロセスのグループには、メイン プロセスの実行を保証するプロセスが含まれます。

• ドキュメンテーション;
• 構成管理。
• 品質保証;
• 検証;
• 認証;
• 学年;
• 監査;
• 問題解決。

組織プロセスのグループには次のプロセスが含まれます。

• プロジェクト管理;
• プロジェクトのインフラストラクチャの作成。
• ライフサイクル自体を定義、評価、改善する。
• 教育。

GOST 12207-99の本文中主要プロセス、補助プロセス、および組織プロセスの一部である作業は非常に一般的に特徴付けられており、実際にはその方向性のみが概説されているため、設計を開始するには、個々のプロセスの内容を明らかにする標準および追加の文献が必要になります。または、さらに良いのは、個人の作品です。
主要なプロセス群の中で、最も興味深いのは開発プロセスです。
GOST 34.601-90「自動化システム」に注意してください。 「作成の段階」では、自動化システムを作成するプロセスは次の段階に分かれています。

• 講演者に対する要件の形成、
• ACコンセプトの開発、
• 技術的なタスク、
• 予備設計、
• 技術プロジェクト、
• 作業ドキュメント、
• 試運転、
• 伴奏。

段階はいくつかの段階に分かれており、その内容は GOST 12207-99 に記載されている多くのタスクの内容と重複します。

開発プロセス

開発プロセス開発者が実行するアクションとタスクを規定し、設計と運用文書の準備を含む、指定された要件に従ってソフトウェアとそのコンポーネントを作成する作業をカバーします。 ソフトウェア製品の性能や適切な品質をテストするために必要な資料、人材トレーニングを組織するために必要な資料などの準備。

図 - 開発プロセスの構造

準備作業

プロジェクトの規模、重要性、複雑さに対応する PS ライフサイクル モデルの選択から始まります。 開発プロセスのアクティビティとタスクは、選択したモデルに対応している必要があります。 開発者は、プロジェクトの条件に合わせて、顧客と合意した標準、手法、開発ツールを選択して使用し、作業実行計画を作成する必要があります。

要件分析

ソフトウェア要件の分析には、各ソフトウェア コンポーネントの次の特性を決定することが含まれます。

• コンポーネントのパフォーマンス特性や動作環境を含む機能。
• 外部インターフェース。
• 信頼性と安全性の仕様。
• 人間工学的要件。
• 使用されるデータの要件。
• インストールと受け入れの要件。
• ユーザー文書の要件。
• 運用と保守の要件。

建築デザイン

システムの概要は、その機器、ソフトウェア、およびシステムを操作する担当者が実行する操作のコンポーネントを決定することです。 システム アーキテクチャは、システム要件と受け入れられた設計標準および慣行に準拠する必要があります。
ソフトウェア アーキテクチャの設計には、(ソフトウェア コンポーネントごとに) 次のタスクが含まれます。

• ソフトウェアの要件を、ソフトウェアの構造とそのコンポーネントの構成を高レベルで定義するアーキテクチャに変換する。
• ソフトウェア システムおよびデータベースのソフトウェア インターフェイスの開発と文書化。
• ユーザードキュメントの暫定版の開発。
• 予備テスト要件とソフトウェア統合計画の開発と文書化。

きめ細かなデザイン

PS には次のタスクが含まれます。

• ソフトウェアコンポーネントとそれらの間のインターフェースの、下位レベルでの説明。その後の独立したコーディングとテストに十分です。
• 詳細なデータベース設計を開発および文書化する。
• ソフトウェアコンポーネントのテスト要件とテスト計画の開発と文書化。

コーディングとテスト

PS では次のタスクがカバーされます。

• 各ソフトウェアコンポーネントとデータベースの開発（コーディング）と文書化、およびそれらをテストするための一連のテスト手順とデータ。
• 各ソフトウェア コンポーネントとデータベースの要件への準拠をテストします。 コンポーネントのテストの結果は文書化する必要があります。
• (必要に応じて) ユーザー ドキュメントを更新します。
• PS統合計画の更新。

集約されたコンポーネントごとに、後続の認定テスト中に各認定要件を検証するためのテスト セットとテスト手順が開発されます。 認定要件とは、ソフトウェア製品が仕様を満たし、現場で使用できる状態にあると認定するために満たさなければならない一連の基準または条件です。

GOST R ISO/IEC 12119-2000 「情報技術。 ソフトウェアパッケージ。 品質要件とテスト」製品が品質要件に準拠しているかどうかをテストする手順を決定する指示が含まれています。 テストは労働集約的なプロセスです。 一部の専門家によると、その割合は
設計、開発、テストのプロセス間の時間配分は 40:20:40 です。 この点で、テスト自動化システムが普及しつつあります。 IEEE 1209-1992 標準「CASE ツールの評価と選択に関する推奨慣行」では、テスト自動化ツールの機能に関する一般要件が定められています。

システム統合

変電所や機器を含むすべてのコンポーネントの組み立てで構成されます。 統合後、システムは一連の要件に準拠しているかどうかの認定テストを受けます。 同時に、システムに関する完全なドキュメントのセットも準備され、検証されます。

システムのインストール

契約によって提供された環境および機器上で、計画に従って開発者によって実行されます。 インストールプロセス中に、ソフトウェアとデータベースの機能がチェックされます。

システムの受け入れ

ソフトウェアおよびシステムの認定テストの結果の評価と、開発者の協力を得て顧客が実行する評価結果の文書化を提供します。 開発者は、必要なトレーニングとサポートを提供しながら、契約に従って顧客へのソフトウェアの最終移転を実行します。 私たちのコースは主に、ソフトウェア開発プロセスの最初の 4 つの作業を詳細に調べることを目的としています。 これらの作業はそれぞれ別のセクションに分けて説明しますが、さらに説明するために、PS ライフサイクル モデルについて少し説明する必要があります。

ソフトウェアのライフサイクルモデル

ライフサイクルモデル– 情報システムのライフサイクル全体を通じて実行されるプロセス、作業、タスクの順序と、それらの間の関係を決定する構造。

現在までに、次の 2 つの主要なライフ サイクル モデルが最も普及しています。

• カスケード (ウォーターフォール) モデル。
• スパイラルモデル。

カスケードモデル

カスケードモデルは、さまざまなアプリケーション分野でさまざまなシステムを開発するための古典的なアプローチを示しています。 情報システムの開発において、このモデルは 70 年代から 80 年代前半に広く使用されました。 これは、GOST シリーズ 34.xxx および米国国防総省標準 DOD-STD-2167A の基礎を形成するカスケード モデルです。 GOST 34.601-90「自動化システム」の GOST 12207-99 を処理します。 創造の段階」はステージと呼ばれ、構成が若干異なります。
カスケード モデルは、プロセスの順次編成を提供します。 さらに、次のプロセスへの移行は、前のプロセスの作業がすべて完了した後にのみ行われます。 各プロセスは、別の開発チームが作業を継続できるように十分なドキュメントの完全なセットのリリースで終了します。

カスケード モデルの主な欠点は、どの段階でもエラーや欠点が、原則として後続の作業段階で発生し、後戻りする必要が生じることです。 コンサルティング会社スタンディッシュ グループによると、1998 年に米国で企業の情報システム プロジェクト (IT プロジェクト) の 28% 以上が失敗に終わりました。 IT プロジェクトのほぼ 46% が予算を超えて完了しました (平均 189%)。 そして、割り当てられた期間と予算の両方に収まるプロジェクトはわずか 26% です。

さらに、カスケード モデルには次のような欠点があります。

• 作業を並列化することが難しい。
• プロジェクト管理の複雑さ。
• 高レベルのリスクと信頼性の低い投資 (以前の段階に戻ることは、エラーだけでなく、開発中に対象領域や顧客の要件に発生した変更にも関連する可能性があります。さらに、これらの理由でプロジェクトを改訂のために戻すことは、プロジェクトの次のバージョンが準備できるまでに、サブジェクト領域が再び変更されないことを保証します。実際、これは、開発プロセスが「循環」し、システムが決してその時点に到達しない可能性があることを意味します。プロジェクトのコストは常に増加し、完成品の納期は常に遅れます)。

スパイラルモデル

カスケードとは異なり、情報システムを開発する反復プロセスが含まれます。 スパイラル モデルは、1980 年代半ばに Barry Boehm によって提案されました。 スパイラルの各ターンはソフトウェア製品のフラグメントまたはバージョンの作成に対応し、プロジェクトの目標と特性が明確になり、その品質が決定され、スパイラルの次のターンの作業が計画されます。 各反復では、プロジェクトの詳細がさらに深められ、一貫して指定され、後続の反復を最適化するために使用されるメトリクス データが収集されます。 ただし、ドキュメントの完全性を保証するためのメカニズムはより複雑になり (特定の要件または定義がテキストで 1 回だけ指定されている場合)、特別なツールの使用が必要になります。
スパイラル モデルの主な特徴:

• 要件を修正し、ユーザーの要件に優先順位を割り当てることを拒否します。
• 最も優先度の高い要件から始めて一連のプロトタイプを開発します。
• 各反復におけるリスクの特定と分析。
• 各反復の終了時に結果を評価し、次の反復を計画します。

迅速なアプリケーション開発

20世紀の90年代に、スパイラルモデルに基づいて「迅速なアプリケーション開発」と呼ばれる実用的な技術、RAD（Rapid Application Development）が創設されました。 この場合、ライフサイクルは 4 つの段階で構成されています。

• 要件の分析と計画、
• デザイン、
• 実装、
• 実装。

RAD の基本原則:

• 繰り返してアプリケーションを開発する。
• ソフトウェアのライフサイクルの各段階での作業のオプションの完了。
• 開発プロセスへのユーザーの関与を義務付ける。
• プロジェクトへの変更と完成したシステムの保守を容易にする構成管理ツールの使用。
• ユーザーのニーズをよりよく理解し、満たすためにプロトタイピングを使用する。
• プロジェクトのテストと開発。開発と同時に実行されます。
• 小規模でよく管理された専門家チームによる開発。
• システム開発の適切な管理、作業の実行の明確な計画と管理。

2001 年初頭、ソフトウェア エンジニアリングの分野の多数の主要な専門家 (マーティン ファウラー、ケント ベックなど) が、新しい設計アプローチである「迅速なソフトウェア開発」 (アジャイル ソフトウェア) をサポートおよび開発するために、アジャイル アライアンスと呼ばれるグループを結成しました。発達）。 このアプローチの実装の 1 つは、エクストリーム プログラミング (XP) です。

エクストリーム プログラミングの原則は次のとおりです。

1. チームは 3 ～ 10 人のプログラマーで構成されます。 1 人以上の顧客が継続的に専門知識を継続的に提供できる必要があります。
2. プログラムは 3 週間の反復で開発されます。 各反復では、顧客がすぐに使用できる、動作するテスト済みのコードが生成されます。 完成したシステムは各リリース期間の終了時にエンド ユーザーに出荷されます。これには 2 ～ 5 回の反復がかかります。
3. 収集されたソフトウェア要件の単位は、インデックス カードに書かれた「ユーザー ストーリー」です。これは、1 回の反復で開発できるユーザーの視点から機能を説明します。 顧客とプログラマは次の方法で次のイテレーションの作業を計画します。
   • プログラマーは各カードを完成させるまでの時間を見積もります。
   • 顧客は優先順位を設定し、必要に応じて変更および修正します。 ストーリーの開発は、プログラマーと顧客専門家の間でのディスカッションから始まります。
4. プログラマーはペアで作業し、プロジェクトの開始時に設定した厳格なコーディング標準に従います。 彼らは、記述したものすべてに対して単体テストを作成し、コードが必須のバージョン管理と構成管理に送信されるたびにそれらのテストが実行されるようにします。
5. プログラマが作業している間、顧客はプログラマを訪問してアイデアを明確にし、反復中に実行するシステム受け入れテストを作成し、反復の最後に次の反復で実装するストーリーを選択します。
6. チームは毎日、運用会議を開催し、プログラマーが現在取り組んでいること、順調に進んでいること、助けが必要なことについて話し合います。 各反復の最後に別の会議があり、何がうまくいったか、次回は何に取り組む必要があるかを評価します。 このリストは、次のイテレーションで作業するときに誰もが確認できるように投稿されます。
7. チーム内に1名を「メンター」として任命します。 彼はチームメンバーと一緒に、ペアのプログラミングとテスト、ペアのローテーション、設計ソリューションのシンプルさの維持、コミュニケーションなどの基本的なテクニックの使用法を評価します。 開発プロセスの継続的な改善を目的としています。

迅速なソフトウェア開発アプローチは普遍的なものではなく、特定のクラスのプロジェクトにのみ適用できます。 このようなプロジェクトを特徴付けるために、アリスター・コバーンは重要性と規模という 2 つのパラメータを導入しました。
重大度はソフトウェアの欠陥によって引き起こされる結果によって決定され、次の 4 つのレベルのいずれかになります。

• C – 欠陥により利便性が失われる。
• D – 欠陥により、回収可能な資金（物的または財務的）の損失が発生します。
• E – 欠陥は、かけがえのない資金の損失を引き起こします。
• L – 欠陥は人命に脅威をもたらします。

規模は、プロジェクトに参加する開発者の数によって決まります。

• 1人から6人まで – 小規模。
• 6人から20人まで - 中規模。
• 20人以上 - 大規模。

コバーン氏によると、迅速なソフトウェア開発は、重要度が低い (C または D) 小規模から中規模のプロジェクトにのみ適用されます。 つまり、RAD および XP テクノロジは、特定の顧客向けに開発された比較的小規模なプロジェクトに最適であり、複雑な計算プログラム、オペレーティング システム、複雑なオブジェクトをリアルタイムで管理するプログラム、および安全性が依存するシステムの構築には適用できません。人の。

統合されたソフトウェア開発プロセス

現在、ある種の普遍的な IS 開発プロセスを作成する作業が続けられています。 1999年 Rational の従業員である Ivar Jacobson、Gradi Booch、James Rumbaugh は、『統一ソフトウェア開発プロセス』という本を出版しました。この本はロシア語に翻訳され、2002 年にピーター出版社から出版されました。統一プロセスは、ウォーターフォール モデルと反復モデルを組み合わせようとする試みです。J C.

同時に、ライフサイクルは 4 つのフェーズに分割されます。

1. 始まり:プロジェクトの初期評価が実行されます。
   • 実装の観点から最も重要なユースケースを含むユースケースの簡略化されたモデルが作成されます。
   • 最も重要なサブシステムを含むアーキテクチャの試用版が作成されます。
   • リスクが特定され、優先順位が付けられます。
   • 設計段階が計画されている。
   • プロジェクト全体を大まかに評価します。
2. 説明（詳細）:ほとんどの使用例は詳細に説明され、システム アーキテクチャが開発されます。 設計フェーズの最後に、プロジェクト マネージャーはプロジェクトを完了するために必要なリソースを計算します。 作業を実行する契約上の義務を与え、「技術仕様」の準備と署名に進むことができるように、ユースケース、アーキテクチャ、および計画は十分に開発されているか?という質問に答える必要があります。
3. 工事– 製品の作成。 このフェーズの終わりには、開発者と顧客が現在のリリースに含めることを決定したすべてのユースケースが製品に含まれます。
4. 実装（移行）– 製品リリース。 製品のベータ版は同社のテスト部門によってテストされ、同時にユーザーによるシステムの試用が組織されます。 その後、開発者は発見したバグを修正し、提案された改善点の一部をメジャー リリースに組み込み、広く配布できるようにします。

USDP の各フェーズには、プロジェクトの規模に応じて 1 つ以上の反復が含まれる場合があります。 各反復中に、5 つのメイン スレッドといくつかの追加のワーカー スレッドを実行できます。
USDP の主な作業ストリームには次のものがあります。

• 要件定義 (RD);
• 分析(A);
• デザイン(P);
• 実装 (P);
• テスト（T）。

追加の作業スレッドには次のものが含まれる場合があります。

• 品質保証業務(K)、
• ドキュメント (D)、
• プロジェクトマネジメント（P）、
• 構成管理 (CM)、
• インフラの構築と管理（I）
• その他。

図 - 統一されたソフトウェア開発プロセスに従ったライフサイクル モデル

ライフサイクル モデルの選択は、開発するシステムの種類と規模に大きく依存します。 自由時間のあるほとんどの自動制御システムの開発には、反復ライフサイクル モデルが適用できますが、リアルタイム システムにはウォーターフォール モデルの方が適しています。 講義では、IS 設計の問題を学ぶ際に、統一モデリング言語 (UML) の使用に特に注意を払います。また、その作成者が Grady Booch と James Rumbaugh であるため、統一開発プロセスのイデオロギーにも目を向けます。 。

図 - 開発プロセスに付随する規制文書

ライフサイクルプロセスのサポート

品質保証プロセス

品質保証プロセスソフトウェア システムとそのライフサイクル プロセスが指定された要件と承認された計画に準拠していることを適切に保証します。 ソフトウェアの品質は、指定された要件を満たすソフトウェアの能力を特徴付ける一連の特性として理解されます。

図 - 補助的なライフサイクルプロセスの構造

GOST R ISO/IEC 9126-93 の文脈において。 "情報技術。 ソフトウェア製品の評価。 品質特性とその使用ガイドライン」 品質特性は、「ソフトウェア製品の品質を記述および評価するためのソフトウェア製品の一連のプロパティ (属性)」として理解されます。

この規格では、重複を最小限に抑えたソフトウェアの品質を表す 6 つの包括的な特性が定義されています。

• 機能性– 一連の関数とその特定のプロパティの本質に関連する一連の属性。 機能とは、明示されたまたは予想されるニーズを実現する機能です。
• 信頼性– 指定された条件下で指定された期間にわたってパフォーマンスのレベルを維持するソフトウェアの能力に関連する一連の属性。
• 実用性– 使用に必要な作業の範囲、および指定されたまたは意図された範囲のユーザーによるそのような使用の個別の評価に関連する一連の属性。
• 効率– ソフトウェア操作の品質レベルと指定された条件下で使用されるリソースの量との関係に関連する一連の属性
• 保守性– 特定の変更（修正）を実行するために必要な作業範囲に関連する一連の属性。
• 可動性– ある環境から別の環境に転送されるソフトウェアの機能に関連する一連の属性。

GOST 28195-89「ソフトウェアの品質の評価。 一般規定"一番上の最初のレベルで、信頼性、正確さ、使いやすさ、効率、汎用性、保守性という 6 つの品質要素を識別します。 これらの要素は、第 2 レベルの 19 の品質基準によって集合的に詳細に説明されます。 品質指標の詳細は、メトリクスと評価要素によって表され、その要素は約 240 あります。それぞれの要素は 0 から 1 の範囲で専門的に評価されることが推奨されます。使用される要素、基準、メトリクスの構成は、選択されることが提案されています。ソフトウェアのライフサイクルの目的、機能、段階に応じて異なります。

GOST 28806-90 規格「ソフトウェアの品質。 用語と定義」プログラム、ソフトウェア ツール、ソフトウェア製品、およびそれらの品質の一般的な概念が形式化されます。 プログラムの特性の評価に関連して最も一般的に使用される 18 個の用語の定義が示されています。 GOST 28195-89に記載されている基本的な品質指標の概念が明確化されました。
ソフトウェアの品質を保証するという問題には、特別な注意が必要です。1998 年 2 月 2 日のロシア連邦政府第 113 号によれば、品質保証および品質管理の国際規格 ISO 9000 の要件への準拠が、ソフトウェアを受け取るための前提条件であるためです。政府の命令。
現段階では、制作・使用されるソフトウェアの品質を評価する手法（出力管理）だけでは不十分で、ソフトウェアのライフサイクルのあらゆる段階で品質を計画し、測定し、調整できることが必要です。品質を向上させるためのソフトウェアの製造プロセス。

ISO 9000 シリーズの規格は一般的すぎます。 ソフトウェアを製造し、ISO 9000 シリーズ規格に基づいた効果的な品質管理システムの導入を希望する各企業は、業界の特性を考慮し、ソフトウェア製品に対する品質要素の実際の影響を反映する品質指標システムを開発する必要があります。 この目的を達成するために、多くの組織は、プロジェクトの立ち上げから始まり、検査とテストを含む、独立した体系的かつ包括的な検証プロセスである品質保証を確立しており、理想的には何らかの独立した組織によって実行されます。 実際には、ほとんどの場合、品質管理は作品の著者の同僚のグループによって実行されます。
検査の目的は、プロジェクトの一部に欠陥がないかチェックすることです。

• ドキュメンテーション、
• 要件、
• 分析結果、
• デザイン、
• リストなど

Fagin, M.著「プログラム開発におけるエラーを減らすための設計とコード検査」(IBM Systems Journal) によれば、検査の関連性は、検査中および統合中のコストと欠陥の検出と修正を比較することによって示されます。 著者の中には、これらのデータが非常に過小評価されていると考える人もいます。

欠陥発見の問題は、金星に送られた数十億ドル相当のアメリカの人工衛星が、軌道修正サブルーチンのタイプミス（カンマの代わりにセミコロンが挿入されていた）により制御を失ってから、より真剣に受け止められるようになった。
品質の評価と改善は、特定のプロセス指標の定量的特性であるメトリクスを使用して実行されます。

検査を実行するには、次の手順が必要です。

1. 検査プロセスは計画から始まります。説明、重大度、タイプによる欠陥の分類が開発されています。 検査を実行する基準の選択、取得したデータを収集および分析するためのツールの選択、検査員間の役割分担が行われます。
   • リーダーは検査を正しく実施する責任があります。
   • 校正者はチームの活動に責任を負い、チームを正しい方向に導きます。 校正者も検査に参加します。
   • レジストラは、チームの慣例に従って、欠陥の説明と分類を記録する責任があります。 登記官も検査に参加します。
   • 専門検査員とは、検査対象の断片が属する特定の狭い分野の専門家です。
2. 必要に応じて、検査の対象をより深く理解するためにレビューワークショップを開催することができます。
3. 検査を実施しています。 検査員は現場で作業全体をチェックします（検査したプログラムコードが詳細設計に該当するかどうかなど）。 検査官は通常、すべての欠陥を説明と分類とともにデータベース (ネットワーク経由でアクセス可能) に記録します。 システムの検査対象部分は論理的に完全である必要があります。
4. 参加者が結果を発表する検査会が開催されます。
5. 著者は欠陥を修正します (改訂フェーズ)。
6. 作業完了後の最終会議で、校正者と著者はすべての欠陥が修正されたことを確認します。 ただし、これは校正者による作品全体の詳細な修正を意味するものではありません。 すべての修正は、自分の作品に責任を持つ著者の責任となります。
7. 他のプロセスと同様に、グループは検査プロセス自体について話し合い、それをどのように改善できるかを決定します。

同社は、今後の検査の評価に役立てるため、検査に費やした時間と検査した作業量の記録を保管しています。 厳しい時間制限の条件下では、いわゆる 各チームメンバーが同僚によって世話される「後見制度」。
すべての品質管理要素を考慮するには、チェックリストを使用すると便利です。 このようなリストには、順番にチェックする必要がある項目が含まれています。
たとえば、IEEE 739-1989 標準に準拠したソフトウェア品質保証計画 (SQAP) では次のように指定されています。

• 誰が品質に責任を負うのか - 個人、マネージャー、グループ、組織など。
• どのような書類が必要か。
• 品質を保証するためにどのような方法が使用されるか（検査、テストなど）。
• プロセス管理中にどのような活動を実行する必要があるか - 会議、監査、レビューなど。

信頼性と安全性

品質の概念に含まれる最も重要な特性の 1 つは信頼性の特性です。
GOST 13377-75 で確立された定義によると、「技術の信頼性。 「用語と定義」によれば、信頼性とは、指定された使用、メンテナンス、修理、保管および輸送のモードおよび条件に対応する指定された制限内で、確立された動作指標の値を長期間にわたって維持し、指定された機能を実行する物体の特性です。 したがって、信頼性はシステムの内部特性であり、その作成中に固有のものであり、運用および運用中に時間の経過とともに明らかになります。
変電所の動作の信頼性は、安定性、つまり故障なく動作する能力と、故障または故障が発生した後の動作状態の復元可能性によって最も広く特徴付けられます。
作成および変更されたプログラムの信頼性と安全性の監視は、品質を確保するために特別に組織された効果的な技術システムを通じて、ソフトウェアのライフサイクル全体に伴う必要があります。 複雑で重要なソフトウェアの品質の検証と確認は、問題志向の認定された認定ラボによる認証によって保証される必要があります。

情報セキュリティ標準は次の 2 つのグループに分類されます。

• セキュリティ要件に従って IP およびセキュリティ機器を評価および分類するために設計された評価基準 - 米国国防総省基準「信頼できるコンピュータ システムの評価基準」、「ヨーロッパ諸国の調和基準」、国際基準「セキュリティを評価するための基準」情報技術」、ロシア国家技術委員会の指導文書。
• セキュリティ ツールと技術の実装と使用のさまざまな側面を規定する仕様。インターネット エンジニアリング タスク フォース (IETF) とその下位部門であるセキュリティ ワーキング グループによって発行されます。

最も重要な評価基準には次のものがあります。

• ロシア国家技術委員会。 案内文書。 コンピューター設備。 ファイアウォール。 情報への不正アクセスからの保護。 情報への不正アクセスに対するセキュリティの指標。 – モスクワ、1997 – は、7 レベルの参照モデルのデータ フロー フィルタリングのレベルに従ってファイアウォールを分類しています。
• ISO/IEC 15408:1999 情報技術のセキュリティを評価するための基準。

2 番目のグループには次のドキュメントが含まれます。

• X.800 「オープン システム相互接続のためのセキュリティ アーキテクチャ」。 認証、アクセス制御、機密性やデータの整合性の確保など、主要なネットワーク セキュリティ サービスが強調表示されます。 サービスを実装するために、暗号化、電子デジタル署名、アクセス制御、データ完全性制御、認証、トラフィック追加、ルーティング制御、公証などのネットワーク セキュリティ メカニズムとその組み合わせが提供されます。
• インターネット コミュニティ仕様 RFC 1510、Kerberos ネットワーク認証サービス (V5) は、ネットワークへのシングル サインオンの概念をサポートすることで、異種分散環境における認証の問題に対処しています。
• X.500「ディレクトリ サービス:概念、モデル、およびサービスの概要」、X.509「ディレクトリ サービス:公開キーおよび属性証明書フレームワーク」。

検証、認証、監査のプロセス

検証、認定、監査は、SQAP IEEE 739-1989 品質管理計画の不可欠な部分です。
検証は、「現段階で計画したとおりに実行できているか?」という質問に答えます。 認証と監査は、「建設中の施設は顧客のニーズを満たしているか?」という質問に答えます。
IEEE 1012-1986 ソフトウェア検証および検証計画 (SVVP) 標準は、検証と呼ばれる認証プロセスと監査プロセスを組み合わせ、その実行方法を定義します。

検証プロセス中に、次の条件がチェックされます。

• システム要件の一貫性とユーザーのニーズがどの程度考慮されているか。
• 指定された要件を満たすサプライヤーの能力。
• 選択された PS ライフサイクル プロセスが契約条件に準拠していること。
• PS ライフサイクルプロセスに対する標準、手順、開発環境の適切性。
• 変電所の設計仕様が指定された要件に準拠していること。
• 入出力データ、イベントのシーケンス、インターフェース、ロジックなどの設計仕様における記述の正確さ。
• コードは設計仕様および要件に準拠しています。
• コードのテスト可能性と正確性、受け入れられたコーディング標準への準拠。
• ソフトウェアコンポーネントをシステムに正しく統合する。
• 文書の適切性、完全性、一貫性。

共同レビュープロセス

共同レビュープロセスプロジェクトの作業状況を評価することを目的としており、主にプロジェクトのリソース、人員、設備、ツールの計画と管理を監視することに重点を置いています。
評価はプロジェクト管理中とプロジェクトの技術的実装中の両方に適用され、契約期間全体を通じて実行されます。 このプロセスは、契約に関与する任意の 2 当事者によって実行され、一方の当事者が他方の当事者を確認します。

問題解決プロセス

問題解決プロセス開発、運用、保守、またはその他のプロセス中に発見された問題 (検出された不一致を含む) の原因や発生源に関係なく、問題の分析と解決が含まれます。 問題解決プロセスはリスク管理と密接に関連しています。 プロジェクトの失敗につながる要因は、リスクという形で現れます。 リスク管理は、特定、排除計画、優先順位付け、排除（または軽減）で構成されます。

リスクが出現する理由としては、次のことが考えられます。

1. 要件の明確でないおよび/または不完全な定式化。
2. プロジェクトへの利害関係者の関与が不十分。
3. 不十分な計画 - 有能なプロジェクト管理の欠如。
4. 範囲、プロジェクトの目標、その他の理由の変更に起因する要件の頻繁な変更。
5. 使用された設計技術の不完全さ。
6. 出演者の知識やスキルの不足。

リスクを防ぐには次の 2 つの方法があります。

1. リスクの原因を排除するためにプロジェクト要件を変更する。
2. リスクの顕在化に伴う問題を解決する技術の開発。

プロジェクト管理プロセス中、マネージャーは、処理を待っているリスクのリストを作成するために、プロジェクトのさまざまな部分のリスクを特定するプロセスを随時開始する必要があります。 リスクごとに、次の 3 つの値が決定されます。リスクが発生する確率。 このリスクが発生した場合、それによってプロジェクトに生じる損害。 リスクを排除するためのコストを見積もる。 すべての値は同じスケールを使用します (例: 1 ～ 10)。

ドキュメントと構成の管理プロセス

「ソフトウェア プロジェクトのドキュメントを管理するには、多大な組織的努力が必要です。なぜなら... ドキュメンテーションは複雑なシステムであり、多くの人々によって同時に変更が加えられる可能性があり、継続的に変更される可能性があります。」 (E. ブラッド)

文書化プロセスでは、PS のライフサイクル中に作成される情報を形式的に説明します。 このプロセスは、すべての関係者 (マネージャー、技術専門家、システムのユーザー) が必要とするドキュメントの計画、設計、開発、作成、編集、配布、保守を行う一連の活動で構成されます。

GOST R ISO/IEC 9294-93。 "情報技術。 ソフトウェア ドキュメント管理ガイド」では、ソフトウェア ドキュメントを効果的に管理するための推奨事項を定めています。 この標準の目的は、ソフトウェアを文書化するための戦略の定義を支援することです。 文書化標準の選択。 文書化手順の選択。 必要なリソースを決定する。 文書化計画の作成。

文書管理完全性と一貫性を保つことを意味します (ここに構成管理を含める著者もいます)。

文書の完全性ソフトウェアのライフサイクルにおける特定のプロセスに伴う一連の文書の基礎を形成する標準および規制文書​​の数によって特徴付けられます。
ドキュメントの一貫性これは、一連の文書に内部矛盾が含まれていないことを意味します。 これは、各仕様を 1 か所のみに配置することによって実現されます。これは、全体的な文書と呼ばれます。 ドキュメントの完全性は、ハイパーリンクの使用によって保証されます。

すべての要件は追跡可能でなければなりませんこれを達成するために、各要件には一意の番号が与えられ、コンセプト開発、設計、そしてメソッドのリストに至るまでこの番号が参照されます。

• // 要件 4.3
• // 著者
• // バージョン
• // 引数
• ...メソッドのリスト...

プロジェクト パーツには、プログラムのソース コードだけでなく、プロジェクト計画を含むすべてのドキュメントも含まれます。 プロジェクトはその生涯を通じて、次の 2 つの方向に変化します。

• まずは新品パーツの入手ですが、
• 2 番目に、既存のパーツの新しいバージョンを入手します。 これらの変更を正確に追跡するために、構成管理プロセスに関連する、特別に編成された一連の管理および技術手順が使用されます。

プロジェクトの各部分を追跡するには、その境界を定義し、構成アイテム (構成アイテム - CI) を識別する必要があります。 構成要素には、クラス、あまり多くはありませんが関数、重要なデータ セット (グローバル テーブル、ドキュメント) があります。 構成の状態の説明は、ソフトウェア コンポーネントの状態を登録し、ソフトウェア コンポーネントのバージョンの実装および拒否されたすべての変更に関するレポートを作成することによって実行されます。 一連のレポートは、システムとそのコンポーネントの現在の状態を明確に反映するとともに、変更履歴を維持します。
構成管理用の特別なソフトウェア ツールがあります (たとえば、Microsoft Visual SourceSafe、Microsoft Visual Studio Team Foundation Server、IBM Rational ClearCase、Subversion など)。

通常、構成管理システムは次の最小要件を満たしています。

• 構成要素を定義する機能。
• システム開発プロセス中に作成または変更された各オブジェクトのバージョンの完全な年表を構成管理データベースに保存します (これには、ソース プログラム コード、ライブラリ、実行可能プログラム、モデル、ドキュメント、テスト、Web ページ、およびディレクトリが含まれます)。
• 地理的に離れた開発チームのサポート。
• 複数の人が同時に構成アイテムを操作することを防ぐための変更権の拒否。
• すべてのシステム オブジェクトに加えられた変更の制御。
• プロジェクトコンポーネントからソフトウェアバージョンを組み立てます。

IEEE が IEEE 828-1990 標準を開発「ソフトウェア構成管理計画 (SCMP)」。 標準のタイトルと構成管理計画の例は、Eric Braude の書籍に記載されています。

図 - 補助的なライフサイクルプロセスの規制文書

組織のライフサイクルプロセス

ライフサイクルの組織プロセスには、インフラストラクチャの作成プロセス、改善のプロセス、トレーニングのプロセス、管理のプロセスが含まれます。

図 - 組織のライフサイクルプロセスの構造

インフラ構築プロセス

インフラストラクチャを確立および提供（維持）するプロセスであり、これには開発、運用、または保守のためのハードウェアおよびソフトウェア、ツール、方法論、標準および条件が含まれる場合があります。 インフラ構築の第1段階では、CASE設計支援システムの選択、プログラミング言語、DBMSの選択を行います。 サポート サービスの組織 - システム管理者、ネットワーク管理者、データベース管理者、秘書など。
文献情報源を使用して選択問題を解決する場合、分類を構築するために最も一般的な手段システムの機能を分析し、特定の分類グループ内で選択が行われるパラメーターを決定する必要があります。
選択手順自体には次の手順が含まれます。

1. 選択したシステムの基本的な指標が特定されます。これは、その機能、制限、リソースなどを考慮して、特定の ACS を設計するときに重要です。
2. すべての指標は表にまとめられています (表 5 を参照)。この表では、専門家の評価に基づいて、各指標に重み係数 Vi (たとえば、1 から 10) が割り当てられ、他の指標と比較したこの指標の重要性を特徴付けます。 すべての重み付け係数の値の合計は、重み付け係数の上限値 (たとえば、10) に等しくなければなりません。
3. 文献情報源および/または専門家から得たデータを使用して、各 j 番目のシステムの i 番目の指標ごとに、有用性 Ui,j の程度が (1 - 最小から 10 - 最大まで) 決定されます。 たとえば、比較的高価な構成管理システムのユーティリティ評価は 1 ですが、無料で利用できるシステムのユーティリティ評価は 10 になります。
4. 比較される j 番目のシステムごとに、評価関数の値が次の式を使用して計算されます。 Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
5. 評価関数の値に基づいて、選択された基準と指定された制限を考慮して、特定のプロジェクトで特定のシステムを使用することの妥当性について結論が下されます。 評価関数の値がより大きいシステムが、比較された選択肢の中から選択する上で最良である。

学習過程

これは、担当者に初期および継続的なトレーニングを提供するプロセスです。 ソフトウェア製品の発注、納品、開発、運用、保守は担当者の資格に大きく依存します。 したがって、ソフトウェア プロジェクトの発注、供給、開発、運用、保守の作業に備えて人材トレーニングを事前に計画し、実施する必要があります。

改善プロセス

ソフトウェアのライフサイクルプロセスを確立、評価、測定、制御、改善するプロセスです。 エンジニアリングの実践では、IS を開発するときに、特定の指標の定量的特性であるメトリクスが使用されます。

最も一般的に使用される指標は次のとおりです。

• 実行された作業量。物理単位で測定されます (コードの行数など)。
• 仕事に費やす時間。
• 欠陥率 (たとえば、コード 1000 行あたりの欠陥数、ドキュメント ページあたりの欠陥数など)。

予備的なまたは望ましいメトリック値が事前に予測され、得られた結果と比較されます。
欠陥に関連する指標は特別な役割を果たすため、その一部をリストします。

1. プロジェクト納品後 12 週間以内に特定されたソフトウェア コード 1,000 行あたりの欠陥の数。
2. 各フェーズでのスケジュールの偏差: (実際の期間 - 計画された期間) / 計画された期間。
3. コストの偏差: (実際のコスト - 計画コスト) / 計画コスト。
4. 合計設計時間 / 合計プログラミング時間 (一部の推定によれば、少なくとも 50% になるはずです)。
5. 欠陥がどの程度発生し、ある段階で検出されるかは、最も単純な指標の 1 つです。

欠陥検出の結果が組織の基準と比較されると、特定のプロジェクトだけでなく、システム作成プロセス全体が評価されます。 各段階で蓄積された欠陥データは、例えば表のようにまとめられる。

「要件形成」段階の分析プロジェクトのすべての段階で欠陥検出の程度が通常よりも低いことを示しています。 より多くの設計欠陥が製造段階ですぐに見つかり、後の段階ではより少ない欠陥が見つかりました。 通常、これは検査によって達成されます。

プロジェクトを改善するためにプロジェクトのライフサイクル全体で実行する必要がある一連のアクションは、たとえば次のようになります。

1. 各フェーズでチームが使用する次のような指標を特定して定義します。
   • 研究、実装、結果の分析に費やされる時間。
   • サイズ (コードの行数など);
   • モジュール内で検出された欠陥の数 (コードの行数など) と欠陥検出のソース。
   • 1 から 10 までのスケールでの品質評価。
2. SQAP で受け取った情報を文書化します。
3. 各フェーズで統計を収集します。
4. 各フェーズでデータ収集を担当する開発者 (たとえば、「品質責任者」) を割り当てます。
5. 将来役立つメトリクス データのレビューを計画します。 メトリクスの値をどのような値にすることができるか、またどのような値にする必要があるかを事前に決定する必要があります。 取得したデータは社内プロジェクトのデータベース作成の基礎となります。

組織能力成熟度モデル

ソフトウェア作成テクノロジーを向上させるプロセスは、組織の戦略計画、その構造、使用されるテクノロジー、一般的な社会文化および管理システムに反映されます。
1990 年代初頭、American Software Engineering Institute (カーネギー メロン大学 (米国ペンシルベニア州ピッツバーグ) の SEI) は、CMM 組織の技術的成熟度のモデル (能力成熟度モデル) を形成しました。 現在、欧米では開発会社がCMMの認証を受けていないと受注が大幅に困難になっています。
CMM は、ソフトウェアの作成と保守のための管理システムを形成するためのルールと、生産文化を段階的かつ継続的に改善するための方法を定義する方法論的な資料です。 CMM の目的は、技術の成熟度や製品の品質に最も影響を与える要因を分析することにより、プロセスの品質を向上させるための戦略を選択するために必要な指示を開発組織に提供することです。 SMM の各レベルで要件が確立され、その要件を満たすことで最も重要なプロセス指標の安定化が保証されます。

管理プロセス

プロジェクト管理は、コスト、能力、品質、スケジュールのバランスをとることです。 プロジェクト管理プロセスには、人事管理、スケジュール設定、プロジェクトのコスト見積もりなど、いくつかの側面が関連しています。

人事管理

チームメンバーの最適な数を決定するための経験データが知られています。

図 - 開発チームの有効性とその構成の依存性

この依存関係により、階層的な管理構造を使用する必要が生じます。

図 - 階層的な管理構造

各従業員の接続数が満足のいくものであるにもかかわらず、彼らは問題の定式化に参加していないため、システム分析の主な要件の 1 つに違反します。つまり、可能な限り最大数の利害関係者が議論に参加する必要があります。問題。
従業員のチームを組織するための代替スキームは、「チーム・オブ・イコール」と呼ばれます。 この場合、すべてのチーム メンバーは階層の同じレベルに属し、役割がメンバー間で分散されます。 また、役割分担は一定期間後に変更される場合があります。 この場合、大規模なプロジェクトでコミュニケーションの数が増加するという問題は、外部コミュニケーションの責任者の役割を強調することで解決されます。

ケント・ベックが提唱したエクストリーム・プログラミングの概念。 開発者と顧客の間の継続的な関係 (そして顧客は開発の参加者の一人となります)、システム開発プロセスとペア プログラミングを根本的に簡素化したいという要望に重点が置かれています。 さらに、ペア プログラミングでは、開発者は 1 台のコンピューターで交代でのみ一緒に作業します。 これにより、一種の継続的検査が実現されます。

スケジュールの準備

ソフトウェア プロジェクト管理計画の作成と維持について説明した標準は数多くあります。 IEEE 1058.1-1987 ソフトウェア プロジェクト管理計画 (SPMP) を使用することをお勧めします。 SPMP は、プロジェクトのさまざまな段階をいつどのように完了するかを定義するスケジュールを提供します。 後続の各設計段階が完了したら、スケジュールを補足および調整する必要があります。 プロジェクトのスケジュールを表示する最も一般的な形式は、ガント チャートです。

図 - ガント チャートの概略図

実行するプロセスがスケジュールされていないときのバッファ期間を計画に含めることをお勧めします。 ガント チャート形式のスケジュールは、ほとんどの場合、Microsoft Office Project を使用して作成されます。
特にプロジェクトを実装するための作業を計画するプロセス、および一般的なプロジェクト管理は、プロジェクトのコストと期間の見積もりに関連します。 この情報はセクション 5.4 に記載されています。 「予算とリソースの割り当て」SPMP、さらにプロジェクトのコストの事前評価は、顧客と請負業者の間の契約の最終版に影響を与える可能性があるため、委託条件に署名する前に実行する必要があります。

PS作成にかかる費用の見積り

労働集約度を見積もるプロセスは、原則としてプロジェクトの開始と同時に始まり、プログラムコードを記述する段階でも継続されます。

労働集約度を評価する最も一般的な方法は次のとおりです。

• アルゴリズムモデリング。この方法は、以前に完了したプロジェクトに関する統計データの分析に基づいており、ソフトウェア製品の何らかの定量的指標 (通常はプログラム コードのサイズ) に対するプロジェクトの労働集約度の依存性が決定されます。 この指標は特定のプロジェクトに対して評価され、その後、モデルを使用して将来のコストが予測されます。
• 専門家の評価。調査は、作成中のソフトウェア製品の適用範囲を知っているソフトウェア開発技術の専門家数名を対象に実施されます。 彼らはそれぞれ、プロジェクトの労働集約度について独自の評価を行っています。 次に、すべての見積もりが比較され、議論されます。
• 類推による評価。この方法は、作成中のソフトウェアの特定のアプリケーション分野で同様のプロジェクトがすでに実装されている場合に使用されます。 この方法は、計画されたプロジェクトを、同様の特性を持つ以前のプロジェクトと比較することに基づいています。 エキスパート データまたは保存されたプロジェクト データを使用します。 専門家は、新しいプロジェクトと以前のプロジェクトの違いに基づいて、高い、低い、最も可能性の高い工数の見積もりを計算します。

それぞれの評価手法には長所と短所があるため、現在では異なる手法を組み合わせたアプローチが採用されています。

ソフトウェア開発の労働集約度を評価する手順は、次の手順で構成されます。

1. 開発中の製品のサイズを見積もる。
2. 労働集約度を人月または人時で評価する。
3. 暦月単位でのプロジェクト期間の見積もり。
4. プロジェクトのコスト見積もり。

ソフトウェア サイズ測定の主な単位は次のとおりです。

• コードの行数 (LOC – コード行数)。
• ファンクションポイント (FP – ファンクションポイント)。

機能規模を評価するための方法論

機能規模を評価するための方法論 (FP – 機能ポイント)アプリケーションのすべての機能を均一に測定し、アプリケーションのサイズを単一の数値で表現することです。 この数値を使用して、コードの行数、コスト、プロジェクトのスケジュールを見積もることができます。
機能サイズを計算するには、システムの情報特性ごとにランクと複雑さが決定されます。 International Function Point Users Group (IFPUG、www.ifpug.org) は、情報の特性を識別するための基準を公開しており、次の 5 つのグループに分類されています。

• – アプリケーション内に配置され、外部入力を通じて提供される、ユーザーが認識する論理的に関連したデータのグループ。

• – 別のアプリケーション内に配置され、別のアプリケーションによって維持される、ユーザーが認識できる論理的に関連したデータのグループ。 特定のアプリケーションの外部ファイルは、別のアプリケーションの内部論理ファイルです。

• – データを外部環境からアプリケーションに移動する基本プロセス。 データは、通信チャネルを通じて、入力画面上のユーザーから、または別のアプリケーションから送信されます。 このデータは内部論理ファイルの更新に使用でき、管理情報とビジネス情報の両方を含めることができます。 制御データは内部論理ファイル (データ入力フィールド、エラー メッセージ、計算値、ボタンなど) を変更してはなりません。

• – アプリケーションで計算されたデータを外部環境に移動する基本プロセス。 さらに、このプロセス中に内部論理ファイルが更新される場合があります。 このデータにより、他のアプリケーションに送信されるレポートまたは出力ファイルが作成されます。 レポートとファイルは、内部論理ファイルと外部インターフェイス ファイルに基づいて作成されます。 さらに、このプロセスでは、内部論理ファイルでサポートされていない検索条件やパラメータを含む入力データが使用される場合があります。 入力データは外部から取得されますが、一時的なものであり、内部論理ファイルには保存されません (レポートのデータ フィールド、計算値、エラー メッセージなど)。

• – 入力データと出力データの両方を処理する基本プロセス。要求と応答の組み合わせで構成されますが、派生データの計算や ILF の更新には関連しません。 その結果は、内部論理ファイルおよび外部インターフェイス ファイルから返されるデータです。 プロセスの入力部分は内部論理ファイルを変更せず、出力部分はアプリケーションによって計算されたデータを運びません (これがリクエストと出力の違いです)。 例: input 要素 - 検索、マウスクリックに使用されるフィールド。 表示要素 – 画面に表示されるフィールド。

GOST R 56376-2015/IEEE C37.92(2005)

ロシア連邦の国家標準

電気測定コンバータ

電子電圧および電流コンバータからの保護リレーのアナログ入力

電気変換器。 電子電圧および電流トランスデューサから保護リレーへのアナログ入力

OKS 17.020

導入日 2016-01-01

序文

序文

1 連邦国家統一企業「全ロシア計量サービス研究所」（FSUE「VNIIMS」）が、第 4 項で指定された英語版規格のロシア語への独自の翻訳に基づいて作成。

2 標準化技術委員会 TC 445「エネルギー効率の高い経済の計測学」によって導入

3 2015 年 3 月 27 日付けの連邦技術規制計量庁の命令により承認および発効 N 192-st

4 この規格は、国際規格 IEEE 規格 C37.92(2005)*「電子電圧および電流トランスデューサーからの保護リレーへのアナログ入力に関する IEEE 規格」、IDT) と同一です。
________________
*本文中に記載されている国内外の文書へのアクセスは、カスタマーサポートに連絡することで入手できます。 - データベース製造元のメモ。


この規格の名前は、GOST R 1.5-2012 (第 3.5 項) に準拠するために、指定された国際規格の名前に関連して変更されました。

この規格を適用する場合、参照国際規格の代わりに、追加の付録に情報が記載されている対応する国内規格を使用することが推奨されます。

5 初めて導入されました

6 再出版。 2019年4月

この規格の適用規則は、 2015 年 6 月 29 日の連邦法 N 162-FZ「ロシア連邦における標準化について」第 26 条 。 この規格の変更に関する情報は、年次（今年の 1 月 1 日現在）の情報索引「国家規格」に掲載され、変更および修正の正式なテキストは毎月の情報索引「国家規格」に掲載されます。 この規格の改訂（置き換え）または廃止の場合は、月刊情報索引「国家規格」の次号にその旨を掲載します。 関連する情報、通知、テキストは、インターネット上の連邦技術規制計量庁の公式ウェブサイト (www.gost.ru) の公共情報システムにも掲載されます。

1使用エリア

1.1 一般規定

この規格は、電圧または電流測定システム、アナログ出力を備えた光センサー、および特別に設計された保護リレーまたはその他の変電所測定装置の間のインターフェース特性を指定します。 これらの測定システムは、電気ネットワーク内の電流と電圧に比例した波形を生成します。

この規格は、単一のリレーまたは測定デバイスで測定する場合に、複数の光学測定センサーの出力から信号を加算または減算するために必要な追加の中間結合器またはスケーリングアンプの要件も指定します。

1.2 目標

測定システムとリレー保護システム間の正規化された測定信号は、最大振幅 ±11.3 V、最大電力 3.2 mW のアナログ電気信号です。

アナログ電子出力を備えた測定システムの例としては、光電子インターフェースを備えた電圧または変流器の光学システムが挙げられます。 図 1 は、高圧変電所における光電流測定システムの要素の典型的な構成を示しています。 この構成では、変流器の光学センサーが高電位バス上に配置されます。 他の場合には、センサーは電源変圧器または絶縁体の内部に取り付けられる場合があります。 光信号は光ファイバ ケーブルを介して接地電位に伝送され、保護リレーやその他のインテリジェント電子デバイス (IED) で使用されるスケーリングおよび正規化された電気信号に変換されます。

光電子変換モジュールは通常、変電所の制御室に設置されますが、開閉装置内の IED の近くに設置することもできます。 この規格は、光電子変換モジュールと、これらの信号を使用する保護リレーまたはその他の IED の間の電気信号の特性を指定します。 光センサーと変換モジュール間のインターフェースは、特定のメーカーが測定システムを構築するための独自の技術ソリューションであり、標準化の対象ではありません。 外部機器と正しく連携するには、変換モジュールの出力、リレー保護端子の入力、およびその他の多くの測定機能の特性を正規化する必要があります。

図 1 でマークされた領域は、この規格で定義されているインターフェイスの位置を示しています。

図 1 - 標準化されたアナログインターフェースを備えた光電流測定システム

2 規範的参照

この規格は、次の規格への規範的な参照を使用します。 日付が記載された参考文献については、引用された版のみが適用されます。 日付のないものについては、最新版（すべての修正と変更を含む）。

IEEE Std 525™、変電所のケーブル システムの設計および設置に関する IEEE ガイド
_______________
IEEE 出版物は、Institute of Electrical and Electronics Engineers, Inc. (445 Hoes Lane, Piscataway, NJ 08854, USA) から購入できます (http://standards.ieee.org/)。


IEEE Std 1050™、発電所における計装および制御機器の接地に関する IEEE ガイド

IEEE Std C37.90™、電力装置に関連するリレーおよびリレー システムに関する IEEE 規格 (電力装置の保護および制御に使用されるリレーおよびリレー システム)

IEEE Std C37.90.1™、IEEE 標準サージ耐力 (SWC) リレーおよび電力装置に関連するリレー システムのテスト (電力機器の保護および制御に使用されるリレーおよびリレー システムの電圧サージに対する耐性のテスト)

IEEE Std C37.90.2™、トランシーバーからの放射電磁干渉に対するリレー システムの耐力に関する IEEE 規格

IEEE Std C57.13™、計器用変圧器の IEEE 標準要件。 IEEE の出版物は、Institute of Electrical and Electronics Engineers, Inc. (445 Hoes Lane, Piscataway, NJ 08854, USA) から入手できます (http://standards.ieee.org/) (計器用変圧器の要件)

3 用語と定義

この規格では次の用語と定義が採用されています。 この規格に記載されていない用語については、「The Authoritative Dictionary of IEEE Standards, Seventh Edition」を参照してください。

3.1 1 つの相対単位 1 ユニットあたり 1 (略称: 1 p.u.): 測定回路の電圧または電流の公称一次実効値測定値に対応する測定出力値または測定システムの出力。

3.2 リレー入力(リレー入力): この規格に準拠するリレー端末、メーター、測定または制御装置、またはインテリジェント電子装置のアナログ電子入力。

3.3 測定システム(感知システム): 電気ネットワーク内で測定された電圧または電流値を生成する電子センサー、デバイス、光電子インターフェース、またはアナログ信号源。その出力はこの規格に準拠しています。

4 一般的な要件

4.1 接続機器

測定システムの出力およびリレー入力には、4.4 の要件に従って高電位サージに耐えることができる一般に入手可能な標準コネクタが装備されているものとします。 コネクタは、接続とケーブルの終端が簡単にできるように設計する必要があります。 ネジ端子が推奨されるソリューションです。 各入力または出力には、4.3 に従ってラベルが付けられた一対の信号端子が含まれています。 機器供給者は、第 7 項に従って、追加の非接地端子またはシールドを接続する手段を提供するものとします。

4.2 アースからのガルバニック絶縁

測定システムの両方の出力端子とリレー入力は、DC または電源周波数信号にさらされる場合、保護接地またはフレーム接地から絶縁する必要があります。 端子とグランド間に許容される静電容量は 0.01 µF を超えてはなりません。

4.3 極性マーキングと逆極性に対する耐性

インターフェイスには、従来の「cts」と「vts」で構成される極性マーキングが必要です。 IEEE 標準 C57.13 を参照してください。
_______________
リンク情報はセクション 2 に記載されています。


測定システムの不平衡出力の場合、信号出力端子には適切な極性マークを付けるか、従来の測定用トランスの二次端子 X1 としてマークする必要があります。

電気ネットワークの一次電流が測定システムの出力で電圧に変換される場合、対応する極性符号を持つ端子の正の電圧値は、対応する極性を持つ一次端子の電流の方向に対応する必要があります。サイン。

各測定システムと各リレーには、非可逆極性でのみ使用可能であること、または逆極性でも使用可能であることを記載したメーカーのラベルが必要です。

極性反転とは、指定どおりにどちらの極性でも接続できる、完全に絶縁またはバランスされた入力または出力を指します。

非可逆極性とは、単線または不平衡入力または出力 (一方の導体が信号の伝送に使用され、もう一方の導体が同軸ケーブルなどのグランド導体として機能する) を指します。これには、信号導体を信号端子とコモン導体はコモン端子のみに接続してください。

通常、測定システムの出力の単一信号は、この信号を使用する複数のリレーまたはデバイスに分岐されます。 この接続を行うときは、次の点を考慮する必要があります。

- 複数のリレーの 1 つ以上の入力が非可逆極性である場合、たとえソースが逆極性であっても、ユーザーはすべてのデバイスに必要な極性接続を常に取得できるとは限りません。

注 - 特定の保護リレーの内部設定またはソフトウェア設定により、入力の極性が変更される場合があります。


- 複数のリレーの各入力に可逆極性が使用されている場合、ソースからの出力が非可逆的でない場合でも、各リレーを必要な極性で接続できます。

これにより、電子測定システムのアナログ出力を使用して、逆極性入力を備えたリレーやその他のデバイスを使用する柔軟性が向上します。

対称または可逆出力端子は、グランドに対して対称である必要があります。

4.4 測定システムの追加出力

4.4.1 警告出力

これは、測定システムの問題を知らせることを目的とした追加信号であり、誤動作、故障、または特性の劣化を通知する必要があります。 メンテナンスまたは修理の必要性を通知します。 たとえば、測定システムへの電源供給に欠陥があると、このような信号が発生する可能性があります。

この出力はタイプ「C」接点で、電位がなく、測定システムの製造元によって指定されている必要があります。 通常の動作条件下では、電力損失や測定システムの故障時にアラームを生成するために、リレー巻線 (コイル) に常に通電する必要があります。

4.4.2 送信データの正当性を示す出力信号

これは、測定システムの電子機器の自己診断中のすべての内部チェックの結果を反映する必要がある必須の信号です。この信号の存在は、アナログ出力信号に問題があり、測定システムの誤動作につながる可能性があることを意味します。接続されたリレー。 また、測定システムの出力信号に大きな誤差が生じる、スイッチオンおよび/またはスイッチオフ時の表示にも使用されます。 接続されたリレーがこの信号を誤ってトリップを禁止するために使用する可能性があります。

この出力は、次のいずれかまたは両方の形式を取ることができます。

- 接触タイプ「A」、無電位、測定システムのメーカーによって指定されています。 通常の正しい動作条件下では、信号を提供したり、誤った出力信号に対する安全ロックを提供したりするために、リレー巻線 (コイル) が常に通電されている必要があります。 連絡は IEEE Std C37.90 に従って行う必要があります。 トリガー効果 (接点バウンス) が発生した場合の出力ブロッキング遅延は 12 ms を超えてはなりません。

- TTL ロジック レベル (0 ～ 5 V) は 1 ms 以上の応答を持ちます (5.8 を参照)。 この場合、論理レベル（５Ｖ）は、送信されたデータの正当性を意味する。

4.5 電磁両立性試験

次のタイプのテストは、測定システムの出力、互換性のあるアナログ電子リレー入力および測定システムの故障を通知する出力、および送信されたデータの正しさを検証するために使用されます。また、リレー入力および中間デバイスについても検証します。第 6 条 この試験は、測定システムのリレーおよび電子機器が周囲の電磁環境の条件に耐える能力に関する他の試験に追加されるものであり、その要件は関連規格に規定されています。

4.5.1 絶縁試験

これらの試験は、IEEE Std C37.90 に記載されている誘電試験方法に従って実施されます。 テスト電圧は、入力端子または出力端子の各ペアと保護アースまたはフレームアースの間にコモンモードでのみ印加されます。 最大 50 V の信号回路は、IEEE Std C37.90 に従って、より低い誘電体テスト電圧でテストされます。

5.1.1 電流測定システムの信号の説明

ダイナミックレンジ: 公称 0.05 ～ 40。

公称出力レベル (または 1 p.u.): 200 mV (rms);

最大瞬時値：0.200×40×1.414＝11.3V（ピーク）。

振幅誤差と位相誤差は、50 または 60 Hz でのスケーリングされた一次信号の実際の値からの最大偏差です。

表 1 - 電流測定システムの信号の説明

非線形歪み係数の合計値は、振幅誤差以下でなければなりません。

信号対雑音比は、信号が 0.1 p.u. を超える場合に 54 dB 以上である必要があります。 測定は電源周波数信号で実行する必要があり、ノイズ測定帯域幅は 120 Hz 以内である必要があります。

電流測定システムには、1 p.u.で公称 2 Vrms、最大出力値 4 p.u.の追加出力を提供できます。 この出力は、要求される測定精度が一般に認められているものよりも高いアプリケーションを対象としています。 保管転送アプリケーションの場合、センサーの製造元は、IEEE Std C57.13 またはその一部などの適切な精度規格への準拠を別途証明する必要があります。

5.1.2 電圧測定システムの信号の説明

ダイナミックレンジは公称値の0.05～2.0倍。

公称出力レベル (または 1 p.u.): 4 V (rms)。

最大出力: 4.0 x 2.0 x 1.414 = 11.3 V (ピーク)。

振幅誤差と位相誤差は、50 または 60 Hz での実際のスケーリングされた一次信号の値からの最大偏差です。

表 2 - 電圧測定システム信号の説明

非線形歪み係数の合計値は誤差値以下でなければなりません。

信号対雑音比は、0.85 p.u. を超える信号で 70 dB 以上である必要があります。 測定は、電源周波数信号と少なくとも 120 Hz のノイズ測定帯域幅を使用して実行する必要があります。

これは、上記の精度が許容できる保護リレーまたは測定アプリケーションに適用されます。

保管転送アプリケーションの場合、センサーの製造元は、IEEE Std C57.13 またはその一部など、関連する精度規格への準拠を別途証明する必要があります。

5.2 位相補正

より高い精度を達成するために、測定システムの製造元は電源周波数での位相補正値を指定する場合があります。その値は、上記で指定した値よりも高い精度を得るためにすべての値に対する補正として入力されます。

注 これは、測定システムが上記の角度誤差に準拠する必要性を排除するものではありません。

5.3 定格荷重

約 5 kOhm の負荷と最大 5 nF の容量性負荷を接続する場合、測定システムの精度はこの規格の要件を満たさなければなりません。 測定システムの 1 つの出力を複数のリレーまたは他の測定デバイスに並列接続できます。 リレーまたはその他の接続デバイスの入力インピーダンスは 50 kOhm 以上、200 kOhm 以下である必要があります。

5.4 コモンモードの低減

測定入力および出力のコモンモード減衰は、最大±50 V のコモンモード信号に対して 50 または 60 Hz で 86 dB より大きくなければなりません。この値は、電流測定システムの入力における 20 V の電圧妨害に対して指定されています。 . 現在の値が 0.5 p.u. で、コモンタイプのノイズが測定信号レベルの 10% 未満である場合。

5.5 出力信号のゼロゾーンからの偏差

出力信号のゼロ ゾーンからの定常状態の偏差 (出力信号の DC 成分のシフト) は 3 mV 未満である必要があります。 これは、アンプ出力における DC 電子機器の要件に関連しますが、「DC オフセット」故障電流信号の指数関数的減衰には適用されません。

アンプのゼロゾーンからの出力信号の定常状態偏差は 3 mV 未満である必要があります。 これは、アンプ出力における長期 DC 電流成分を伴う電子特性を指しますが、短絡電流信号の「DC オフセット信号」の指数関数的減衰とは関係ありません。

5.6 帯域幅と過渡応答

測定システムの供給者は周波数応答を指定する必要があります。 5.1 で指定された電源周波数 (主電源周波数) の偏差は 45 ～ 65 Hz でなければなりません。 応答は、3 kHz までは少なくとも 0 ～ -1 dB、5 kHz までは 0 ～ -3 dB である必要があります。 下側カットオフ周波数 (存在する場合) は、システムが一定の信号オフセット応答に対する次の要件を満たすことができるように設定する必要があります。

一次電流の指数関数的減衰応答 (「定信号オフセット」) を 20 p.u. の値で完全にオフセットするには、 瞬間スケーリング係数誤差は、100 ms までの時定数に対して 10% を超えてはなりません。

一次電圧の場合、過渡応答はステップパルスに対する応答によって決まります。 範囲内のパルス形状の値をゼロに変更しますが、測定システムの出力の信号は 4 ミリ秒以内に初期値の 10% 未満のレベルに減少し、その後にのみ 10% 未満に低下する必要があります。この時。

顧客によっては、精度要件を緩和して 65 ～ 75 Hz の範囲の周波数でシステムを動作させる必要がある場合があります。 測定システムの供給者が、この周波数範囲での動作の技術的特性の要件を定義することをお勧めします。

5.7 エラー信号検出の設定

重大な問題や誤警報の発生を避けるために、内部障害が検出された場合、測定システムのインターフェース出力をゼロにラッチする必要があります。 これは、測定システムへのバックアップ電源供給、または過渡状態でのシャットダウンによって確保されます。 問題の特定から修正までの時間は 0.2 ミリ秒以内である必要があります。

通常、問題の特定は、4.4.2 で説明した、出力からデータを送信するための正確性チェック中に行われるエラー検出と同じ方法を使用して実行されます。

5.8 送信データの正確性を示す信号の説明

4.4.2 データ有効性情報を伝達するオプションの信号は、TTL レベル信号 (0 または 5 V) であり、保護接地から絶縁され、アナログ測定システム信号の送信と同じ接続方法を使用して送信されることを目的としています (セクションを参照) 7）。 3.0 ～ 5.5 V の論理ユニットは、測定システムの出力に正しいデータが存在することを通知します。 0 ～ 0.5 V の範囲の論理ゼロは、測定システムの出力でのデータ エラーを示します。 このオプションの信号の出力は、指定された仕様内の電圧を 200 オーム以上の負荷インピーダンスに供給できなければなりません。 トリガーイベントから出力状態の変化までの遅延は 1 ミリ秒を超えてはなりません。

この信号を受信する保護リレーの入力回路は、保護接地から絶縁し、2 kΩを超える入力抵抗を持たなければなりません。 この場合、2.5 V を超えるレベルの信号のみが論理ユニットとして認識される必要があります。

6 中間デバイス

6.1 目的

中間デバイスを使用して、測定システムの個々の出力の合計または差を作成できます。 また、測定システムの単一出力に接続されているさまざまなタイプのリレーまたはメーターの入力を絶縁するために使用することもできます。 中間デバイスはユニティゲインを持つ場合もあれば、測定システムのゲインを変更するための個々の入力のスケーリングを含む場合もあります。

中間デバイスを使用して、従来の計器用変圧器の出力と測定電子システムの出力を一致させることもできます。 このセクションで定義されている動作要件は、アナログ電子出力を備えた中間デバイスにのみ適用されます。

6.2 中間デバイスの性能要件

中間デバイスの精度、帯域幅、信号対雑音比は、測定システム自体よりもはるかに優れている必要があります。 中間デバイスの要件は次のとおりです。

表 3 - 中間デバイスのパフォーマンス要件

アンプの性能要件は、入力コネクタと出力コネクタとともに満たす必要があります。 性能要件はユニティゲインで決定する必要があります。 メーカーは非単一ゲインでの性能特性を指定する必要があります。

6.3 中間デバイスのその他の要件

中間デバイスは、セクション 4 および 5 の他のすべての要件に準拠するものとしますが、6.2 で指定された要件には準拠しません。 IEEE Std C37.90 で指定されている動作、輸送、保管条件の範囲内の要件を満たさなければなりません。

7 中間デバイスのインストール手順

図 2、3、および 4 は、単一および複数のソースおよび負荷の接続例を示しています。 これらは、測定システムと最も遠いリレー入力の間の距離が 50 m 未満の場合の適切な接続を示すために示されています。 シールド付きツイストペア導体は、通常、一般的な変電所制御センター内に設置されます。そこでは、短絡が発生したときの接続されたシステムのゼロ電位間の差が 20 V を超えません。24 AWG 以上の断面積を持つ導体は、非常に優れています。これらの目的には許容されます。 複数のツイストペアが 1 つの共通シールド内に封入されている場合、差動接続中のチャネル間の相互影響は 70 dB のレベルを超えてはなりません。

すべての図面に共通する次の主な特徴に注意する必要があります。

- 有線接続は、機器がセクション 4 で指定されているコモンモード除去テストに合格しており、セクション 5 で指定されているコモンモード除去比がわかっていることを前提としています。

- ツイスト信号導体はどの点でも接地されていません。

- シールドの一端（通常はリレー側または接続の受信端）のみが直接接地されます。 複数の測定システムや複数のリレー設置の場合、単一のシールド接地点が定義されます。 この接地は静電シールドのみを提供し、電源周波数での磁気シールドは提供しません。 複数のリレーに接地点を 1 つだけ提供するには、単一の接地点を提供しながらシールドをデイジーチェーン接続できます。

- 安全接地インターフェースの共通出力または無極性出力に内部接続されている、シングルエンドまたは非可逆極性の計量システムまたはリレーは、信号の問題を引き起こしたり、他のデバイスの絶縁安全性を損なう可能性があることに注意してください。

図 2 - 1 つの測定システムと 1 つのリレー入力

図 3 - 複数のリレー入力を備えた 1 つの測定システム

図 4 - 複数の測定システムと中間デバイス

- 改善された高周波電磁シールドを提供するために、追加の 10 nF セラミック ディスク コンデンサをシールドと各非接地シールド接続点の間に取り付けることができます。 ユーザーが設置することも、メーカーの機器内に設置することもできます。 このようなコンデンサの取り付けは、短い制御ケーブルでは一般に許容されますが、長い制御ケーブルでは高周波シールドに問題が生じることに注意してください。

高品質の高周波電磁シールドを行うための好ましい条件がない屋外開閉装置に設置されたスイッチ装置を接続するには、顧客はシールド方式、シールドの接地、および要素の絶縁についてより慎重に検討する必要があります。 IEEE 標準 525 を参照してください。

この場合、低レベル測定信号に対するツイストペアシールド内の工業用周波数の磁場および電磁場によって誘導される電流の影響を排除するには、両端で接地された追加の信頼性の高い外部シールドが必要です。 この場合、電子信号源を接地電位から絶縁する必要があります。

付録 A (参考用)。 安全な使用

付録 A
(参考)

最新のアナログ電子測定システムと、計器用変圧器を備えた従来の受動的測定システムとの間には、動作に大きな違いがあります。

アプリケーションにとって新しく、特に重要なのは、低周波領域の特性、システムのオン/オフ時の過渡プロセス、電気ネットワークの過渡条件への応答、位相遅延、電気ネットワークの過渡条件への応答、位相遅延、出力です。負荷容量、故障および緊急信号、校正。 アナログインターフェイスとデジタルインターフェイスの対比については議論中です。

A.1 低周波領域の振幅周波数応答

従来の鉄心コンバータは、デバイスが特定のボルト/ヘルツ制限を超える交流で飽和するまで、低周波数に応答します。 つまり、このようなコンバータでは、低周波数での歪みなく、非常に低い信号レベルのみが再生されます。 飽和は現在の半サイクル中に突然発生し、出力信号は極性が反転するまで完全に突然消えます。 一方、この規格で指定されているアナログ電子測定システムでは、低周波数のロールオフが発生したり、信号の DC 成分が完全に欠落したりする可能性があります。 ローパスフィルターを組み込むと、リレーやその他の高速測定システムが設計されていないさまざまな予測不可能な過渡現象が発生する可能性があります。 具体的な現象には、基準点のシフト、指数関数的に減衰する過渡特性に対する不正確な応答 (一定のバイアス電圧の出現)、および入力過渡特性に対する応答としての低周波減衰振動プロセスが含まれます。

リレーの設計者は、測定アルゴリズム、特に故障電流でよく発生する DC オフセットからの動作用に特別に設計された低周波コンポーネントの影響を評価する必要があります。 5.6 で指定された精度には、DC バイアス動作の要件が含まれます。

A.3 ステップ応答

過渡モードまたは過渡応答は、測定システムの電子機器における対応するハイパス フィルター特性と密接に関係していますが、周波数帯域幅に応じて大幅に変化する可能性があります。 短絡とスイッチングにより、正または負の出力オーバーシュートが発生し、高周波発振が減衰する可能性があります。

ユーザーは、これらの歪みに対するリレーの応答を確認する必要があります。 正または負のサージによって高速リレーが誤動作する可能性があることに注意してください。

また、広帯域高速差動回路では、異なるメーカーの異なる世代の測定システムの伝達特性に違いがあり、それが不正確な異なる出力値をもたらし、信頼性の低下や信頼性の低下につながる可能性があることも知っておく必要があります。誤検知さえも。

接続されたマイクロプロセッサ保護リレーのエイリアシング効果 (サンプリング中の) を除去するためのアンチエイリアシング フィルタ (アンチエイリアシング フィルタ) のカットオフ周波数が、測定システムの帯域幅および既存の周波数歪みより 3 倍以上低い場合、問題は発生しない可能性があります。 。

5.6 には、ステップパルスへの応答によって決定される測定システムの過渡特性が含まれることに注意してください。

A.4 位相遅れ

電気ネットワーク内で測定された主な値が、測定システムが接続された中継システムに提示するまでの時間遅延は、測定時間間隔に比べて短く、一見すると重要ではありません。 ただし、これは、2 つの異なるタイプの測定システムから得られる 2 つの量を比較するリレーまたは測定システムにとって深刻な問題になる可能性があります。 差動電流の比較は、高速回路が 2 つの測定システム間の位相遅延の差に敏感である好例です。 距離リレーと方向リレー、特に商用エネルギー メーターは、電圧と電流の関係を正確に一致させる必要があるため、問題が発生する可能性もあります。

電圧測定システムは、一次電流信号と電圧信号の測定における遅延が同一であることを保証せずに、電流測定とは異なる方法を使用します。

セクション 5.2 では、メーカーが提供する位相補正を選択するための追加オプションについて説明します。

A.5 耐荷重

測定システムの電圧出力モードは、入力の並列グループとみなされる、接続された負荷全体に電流を供給できなければなりません。 負荷の増加は信号生成精度の低下につながる可能性があり、信号生成精度はソースインピーダンスによって決まりますが、出力信号は多くのアプリケーションで使用できます。 従来の変流器および電圧変圧器 (CT および VT) の負荷の影響を考慮して並列を引くことができます。

A.6 障害とアラーム

設計者は、特に電子コンポーネントの故障モードを判断し、光ファイバー ケーブルの損傷、破損、亀裂などの事象の影響を評価できなければなりません。 すべての問題を回避することは不可能ですが、一部の問題を防ぐための追加の安全対策があります。

この点に関して、設計者は、出力信号の減衰または抑制を検出できる自己監視システムの高性能に関するデータを提供することで支援できます。 減衰された出力信号が差動保護リレーに干渉する可能性があり、追加のデータ無効信号を使用してトリップを禁止しない限り、誤ったトリップが発生する可能性があることに注意してください。 リモートリレーの電圧が失われると、誤動作が発生したり、潜在的なロジック (使用されている場合) の損失が引き起こされ、保護機能が大幅に制限されます。

測定システムが軽微な問題を自己診断し、抑制やブロックを行わずに非緊急アラームを発する機能により、保守担当者は悪影響が生じる前に問題を解決できる見通しが得られます。 モデムまたは WAN ポート経由で指定された診断を報告できるデータ通信ポートにより、修理技術者が正しい部品や機器を持って到着する可能性が高まります。

A.7 校正

供給者は、測定システムの初期校正の実行方法とその後の保守方法についてユーザーを訓練する義務があります。 特に、付属の IED が校正手順の実行に必要な特性を備えていることを確認してください。

測定システムのサプライヤーは、故障した電子変換モジュールを交換する際にシステムの校正をどのように行うかを顧客に指示する必要があります。

A.8 デジタルインターフェース

この規格は、デジタル データ インターフェイスを備え、メーカーとユーザーの両方にとってアナログ インターフェイスの相互運用性が重要である大規模システムに組み込まれたものを含む、低レベルのアナログ インターフェイスのみを対象としています。

デジタルインターフェイスには、サンプリングプロセス、パフォーマンス、および測定システムとリレー間の通信のための多層通信プロトコル層の仕様が必要です。 電気ネットワーク情報を提供するためのデジタル データ インターフェイスは、IEC 61850-9-1、IEC 61850-9-2、IEC 60044-7、および IEC 60044-8 で提供されます。

付録 はい (必須)。 参考国際規格と国内規格との適合性に関する情報

適用はい
（必須）

表 DA.1

参考文献

IEEE P1331 ドラフト 8.3、1999 年 4 月: 保護リレーへの低エネルギーアナログ信号入力の試用標準

電子文書テキスト
Kodeks JSC によって作成され、以下に対して検証されています。
公式出版物
M.: スタンダード、2019

講義3

ソフトウェアのライフサイクル

ライフサイクルの定義に含まれる基本概念

開発プロセス

開発プロセス

10. システム要件の分析

11. ソフトウェア要件の分析

12. ソフトウェアアーキテクチャの設計

13. ソフトウェア詳細設計（ソフトウェア開発作業計画）

14. ソフトウェアのコーディングとテストには、次のタスクの解決が含まれます。

15. システム統合

16. ソフトウェア認定テスト

17. ソフトウェアのインストールと受け入れ

18. ソフトウェアの操作

19. ソフトウェアメンテナンス（IEEE – 90規格に準拠）

20. ソフトウェアライフサイクルのサポートプロセス

21. 文書化プロセス

22. 構成管理

23. 品質保証プロセス

24. 検証

25. 認証

26. ソフトウェアライフサイクルの組織プロセス

27. ESPD規格のグループ

28. ESPD文書のリスト

29. ESPD 標準を使用する利点

30. ESPD規格の欠点

31. 標準 GOST 34.601-90: 自動化システムの作成の段階と段階

32.