what is stlc v model
STLC Vモデルとは何ですか？
の主要なハンディキャップの1つ ウォーターフォールSTLCモデル テストは開発サイクルの最後に行われたため、開発プロセスの非常に後の段階で欠陥が見つかったということでした。それは非常に後の段階で発見されたので、欠陥を修正することは非常に困難で費用がかかるようになりました。この問題を克服するために、「Vモデル」と呼ばれる新しい開発モデルが導入されました。
Vモデルは、現在最も広く使用されているソフトウェア開発プロセスの1つです。 Vモデルの導入により、要件フェーズからテストが実装されていることが実際に証明されました。 Vモデルは、検証および妥当性確認モデルとも呼ばれます。
学習内容：
検証と妥当性確認
Vモデルを理解するために、まずソフトウェアでの検証と妥当性確認とは何かを理解しましょう。
検証 ： 検証は静的分析手法です。この手法では、コードを実行せずにテストが実行されます。例としては、レビュー、検査、ウォークスルーなどがあります。
検証 ： 検証は、コードを実行することによってテストが行われる動的分析手法です。例には、機能的および非機能的なテスト手法が含まれます。
Vモデル
Vモデルでは、開発とQAアクティビティが同時に実行されます。テストと呼ばれる個別のフェーズはありません。テストは要件フェーズから始まります。検証と妥当性確認のアクティビティは密接に関連しています。
Vモデルを理解するために、次の図を見てみましょう。
典型的な開発プロセスでは、左側が開発活動を示し、右側がテスト活動を示します。開発段階では、検証と妥当性確認の両方が実際の開発活動とともに実行されると言っても間違いありません。
次に、図を理解しましょう。
左側
先に述べたように、左側の活動は開発活動です。通常、私たちは感じます、 開発段階でどのようなテストを行うことができますか？ しかし、これはこのモデルの美しさであり、開発活動のすべての段階でもテストを実行できることを示しています。
要件分析 ：このフェーズでは、要件が収集、分析、および調査されます。ここでは、システムがどのように実装されているかは重要ではありませんが、システムが何をすることになっているのかは重要です。ブレーンストーミングセッション/ウォークスルー、インタビューは目的を明確にするために行われます。
- 検証活動 ：要件のレビュー。
- 検証活動 ：UATの作成（ ユーザー受け入れテスト ）テストケース
- 生成されたアーティファクト ：要件理解ドキュメント、UATテストケース。
システム要件/高レベルの設計 ：このフェーズでは、ソフトウェアの高レベルの設計が構築されます。チームは、要件をどのように実装できるかを調査および調査します。要件の技術的実現可能性も調査されます。チームは、作成されるモジュール/依存関係、ハードウェア/ソフトウェアのニーズも考え出します。
- 検証活動 ：デザインレビュー
- 検証活動 ： の創生 システムテスト計画 と事例、トレーサビリティ指標の作成
- 生成されたアーティファクト ：システムテストケース、実現可能性レポート、システムテスト計画、ハードウェア-ソフトウェア要件、作成するモジュールなど。
建築デザイン： このフェーズでは、高レベルの設計に基づいています 、 ソフトウェアアーキテクチャが作成されます。モジュール、それらの関係、依存関係、アーキテクチャ図、データベーステーブル、テクノロジの詳細はすべて、このフェーズで完成します。
- 検証活動 ：デザインレビュー
- 検証活動 ：統合テスト計画とテストケース。
- 生成されたアーティファクト ：設計ドキュメント、統合テスト計画とテストケース、データベーステーブルの設計など。
モジュール設計/低レベル設計： このフェーズでは、ソフトウェアコンポーネントのすべてのモジュールが個別に設計されます。メソッド、クラス、インターフェイス、データ型などはすべてこのフェーズで確定されます。
- 検証活動 ：デザインレビュー
- 検証活動 ：ユニットテストケースの作成とレビュー。
- 生成されたアーティファクト ：ユニットテストケース、
実装/コード ：このフェーズでは、実際のコーディングが行われます。
- 検証活動 ：コードレビュー、テストケースレビュー
- 検証活動 ：機能テストケースの作成。
- 生成されたアーティファクト ：テストケース、チェックリストを確認します。
右側
右側は、テストアクティビティまたは検証フェーズを示しています。下から始めます。
グラフ実装c ++隣接リスト
ユニットテスト： このフェーズでは、低レベルの設計フェーズで作成されたすべての単体テストケースが実行されます。
*単体テストはホワイトボックステスト手法であり、コードスニペットが期待どおりの出力を提供しているかどうかをテストするメソッド（またはその他のコード）を呼び出すコードが記述されます。このテストは基本的に開発チームによって実行されます。異常が発生した場合は、欠陥がログに記録され、追跡されます。
生成されたアーティファクト ：単体テストの実行結果
統合テスト ：このフェーズでは、アーキテクチャ設計フェーズで作成された統合テストケースが実行されます。異常が発生した場合は、欠陥がログに記録され、追跡されます。
*統合テスト：統合テストは、ユニットテストされたモジュールが統合され、統合されたモジュールが期待される結果を提供しているかどうかをテストする手法です。簡単に言うと、アプリケーションのコンポーネントが期待どおりに連携するかどうかを検証します。
生成されたアーティファクト ：統合テストの結果。
システムテスト ：このフェーズでは、すべてのシステムテストケース、機能テストケース、および非機能テストケースが実行されます。言い換えれば、アプリケーションの実際の本格的なテストはここで行われます。欠陥はログに記録され、その閉鎖のために追跡されます。進捗状況の報告もこのフェーズの主要な部分です。トレーサビリティメトリックが更新され、カバレッジとリスクが軽減されていることが確認されます。
生成されたアーティファクト ：テスト結果、テストログ、欠陥レポート、テスト要約レポート、および更新されたトレーサビリティマトリックス。
ユーザー受け入れテスト ：受け入れテストは、基本的にビジネス要件テストに関連しています。ここでは、ユーザー環境でビジネス要件が満たされていることを検証するためのテストが行われます。互換性テストおよび場合によっては機能しないテスト（ 荷重、応力、および体積 ）テストもこのフェーズで行われます。
生成されたアーティファクト ：UATの結果、更新されたビジネスカバレッジマトリックス。
Vモデルはいつ使用しますか？
Vモデルは、次の場合に適用できます。
- 要件は明確に定義されており、あいまいではありません
- 受け入れ基準は明確に定義されています。
- プロジェクトのサイズは短〜中です。
- 使用されるテクノロジーとツールは動的ではありません。
Vモデルを使用することの長所と短所
| 長所 | 短所 |
|---|---|
| -開発と進歩は非常に組織的で体系的です | -大規模で複雑なプロジェクトには適していません |
| -中小規模のプロジェクトに適しています。 | -要件が一貫していない場合は適切ではありません。 |
| -テストは最初から開始されるため、あいまいさは最初から識別されます。 | -中間段階では、動作するソフトウェアは作成されません。 |
| -各フェーズには明確に定義された目的と目標があるため、管理が簡単です。 | -リスク分析を行うための規定がないため、不確実性とリスクがあります。 |