システムの顧客に対するどの段階にも時間、追加のスタッフ作業、および金銭的費用がかかるため、プロジェクトの期間からテスト期間をスキップできる機能を紹介します。
システム/ソフトウェア製品の品質要件
ステージをスキップする際の最も重要なことは、開発中の製品の品質を失わないことです。 これを行うために、 GOST R ISO / IEC 25010-215の品質要件のセクションを分析します。 システムの品質（ソフトウェア製品）の主な特徴を提供します。
- 機能的適合性
- パフォーマンスレベル
- 互換性
- 使いやすさ
- 信頼性
- 保安
- 同伴性
- 移植性。
GOSTは要件の完全なリストを提供するため、各要件への回答は、テスト運用段階なしでプロジェクトの実行可能性と経済効率の完全な全体像を提供します。
機能的適合性。 機能モデリングの段階（システム開発の開始前）で、特定された制限を説明します。これらの制限は、重要度に従って分類する必要があります。 「重要な発言」の重みが最も大きく（図のカテゴリ1）、これは提案されたシステムまたはその一部を使用することが不可能であることを意味します。
設計前の作業で重要なコメントが特定されなかった場合、ほとんどの場合、発売時にコメントはありません。 重要な要件の出現に伴う修正の場合は、テスト期間を含めることができる段階のレビューが続きます。
カテゴリー2および3の欠陥は、コメントの同時削除を確実に行うのに十分なリソースがあれば、産業運用の段階ですでに対処できます。
パフォーマンスレベル。 プログラムを開発するためのモジュール式アプローチは、それらだけでなく、他のすべてのものも、新しいシステムの立ち上げを大幅に簡素化します。 クアドロコプターを開発している場合、メーカーの電気モーター、プロセッサー、アンテナの技術的特性の詳細な説明を含むコンポーネントを使用して、TTX表現のデバイスをすばやく構築できます。 技術専門家はベンダーの製品に精通している必要があり、アナリストはプロジェクトの機能を考慮する必要があります。
たとえば、1C：BSP（Library of Standard Subsystems）は、多数のプログラムで使用されています。 プロジェクトの前に実際の動作条件で繰り返しテストされているため、パフォーマンスをテストすることは意味がありません。 さらに、より良いメーカーを作成することは成功しそうにありません。
大規模な社内モジュールまたは大規模プロジェクトにはテストが必要です。
互換性。 デフォルトでは、統合システムはすべてのサブシステムの操作を提供します。 パッチワークでは、ソフトウェアモジュールとハードウェアの両方の互換性を分析する必要があります。 プログラム 、DBMS、Webサービス、実際に使用されなかった機器間の互換性には検証が必要です。
使いやすさ。 プロジェクト前の審査に関するコメントの確認に戻ると、重要なコメントだけでなく、「不便をもたらす」こともあります。 たとえば、ドキュメントに金額を入力するサービスがないことは重要ではありません。計算機でいつでも計算して手動で入力できるからです。
月の向こう側を忘れないでください。テスト期間は、2つのシステム（新旧）で作業する従業員の負荷を増加させ、ドキュメントの量を手動で入力するよりもさらに不便です。
信頼性 これは、システムが長時間動作状態を維持する能力です。 技術プラットフォーム「1C Enterprise 8」に基づいた自動化プロジェクトを検討する場合、いくつかの条件によって信頼性が確保されます。
- 技術プラットフォーム1C、DBMSの信頼性（開発者に依存）。
- システムの技術的およびソフトウェアアーキテクチャの適格な構築。
- 資格のあるセットアップ。
どのベンダーからもエラーがあります。 繰り返しますが、 人口が35万人のトヨタ企業であっても、生産エラーのために自動車をリコールしている場合でも、エラーを排除するための更新プログラムを発行するのは1Cプラットフォームです。
間違いは異なりますが、いくつか魅力的です:)
1cアーキテクトからは、専門的で費用対効果の高いソリューションが必要です。 多数の運用ドキュメントが導入されている場合、信頼性のために、サーバークラスタリングとレプリケーションを備えたクライアントサーバーオプションが必要です。 多くのドキュメントがあり、ユーザーが少ない場合は、クライアントファイルモードで十分です。
ユーザー数のオプションを選択するための一般的なルールはありません;分析的アプローチが必要です。 マネージャー、セラー、キャッシャー、ストアキーパーなどの異なる役割を持つ10人のユーザーを配置すると、ファイルオプションがプルされ、10人のキャッシャーがあれば、間違いなくクライアントサーバーオプションになります。 アナリストは、リソースの競合プロセスを理解しています。
また、技術的な構造が破壊され（メガホンの世界的な失敗に関するニュースを背景にこのテキストを書く）、信頼性は、とりわけデータの永続性とアーキテクチャの復元速度を意味することにも注意する必要があります。
例1Cの続きで、実際には毎日アーカイブを行うことに注意してください。 現在の稼働日には、過去90日間のアーカイブがあり、その後毎月1コピーが必要です。
信頼性をテストする必要がありますか？ これが複雑なアーキテクチャである場合、最大のシステム機能を決定するために、秋まで負荷テストが必要です（タスクはベースを削除することです）。
セキュリティ。 機密情報の保護が深刻な場合は、テスト操作をスキップせずに、システムにアクセスするための技術的なタスクを開発することを強くお勧めします 。
新しいシステムでユーザー権限を操作するには、2つの方法があります。
- 「より大きなものからより小さなものまで」-すべてのユーザーにフルアクセスを許可し、プロジェクトの安定した状態の後、制限プロセスを開始します。
- 「最小のものから最大のものへ」-必要な最小限の権利セットを作成し、リクエストを受け取ったときにそれを増やします。
最初のケースでは、テスト操作をスキップすることができますが、多くのユーザーが「追加の」情報にアクセスできることに注意してください。
情報への許可されたアクセスに加えて、一般的なセキュリティ問題（パスワードの破り、データアーカイブのコピーなど）を解決する必要があります。 これらのアクションは、オペレーティングシステムまたは補助ソフトウェアによって構成されます。
伴奏と公差。
テスト期間の期間が1か月を超えることはめったにありません。 これは、スタッフの人件費が高いためです。 経済的に不採算。
これらの定義とテスト操作の間には大きなつながりはありません。
まとめ
上記のすべてのポイントを分析し、SWOT分析を行い、実行可能性を決定します。 ただし、いずれにしても、 テスト操作なしで実行する場合は、この項目をリスクレジスタに含め、それに対する反応を説明してください 。
件名「Risks」を示すメール「doc@ingraf.su」でリスク登録テンプレートを入手できます。