ソフトウェアレビュー

フリー百科事典ウィキペディアより

ソフトウェアレビューとは、「プロジェクトの担当者、マネージャー、ユーザー、顧客、ユーザーの代表者、またはその他の利害関係者が、コメントや承認のためにソフトウェア製品を検査するプロセスまたは会議」です。[1]

このコンテキストでは、「ソフトウェア製品」という用語は、「ソフトウェア開発活動の成果物として作成された技術文書または部分的な文書」を意味し、契約、プロジェクト計画および予算、要件文書、仕様、設計などの文書を含む場合があります。ソース コード、ユーザー ドキュメント、サポートおよびメンテナンス ドキュメント、テスト計画、テスト仕様、標準、およびその他の種類の専門家の作業成果物。

さまざまなソフトウェア レビュー

ソフトウェアのレビューは、次の 3 つのカテゴリに分けられます。

さまざまな種類の査読

  • コード レビューは、コンピューター ソース コードの体系的な検査 (多くの場合、ピア レビュー) です。
  • ペア プログラミングは、 2 人が同じワークステーションで一緒にコードを開発するコード レビューの一種です。
  • 検査は、レビュー担当者が明確に定義されたプロセスに従って欠陥を見つける非常に形式的なピア レビューです。
  • ウォークスルーは、作成者が開発チームのメンバーをリードし、他の関係者がソフトウェア製品を調べ、参加者が質問をしたり、欠陥についてコメントしたりするピア レビューの形式です。
  • テクニカル レビューはピア レビューの形式であり、資格のある担当者のチームがソフトウェア製品が意図した用途に適しているかどうかを調べ、仕様や標準との相違点を特定します。

正式なレビューと非公式のレビュー

「形式」とは、合意された (書面による) 規則によって活動が管理される程度を示します。ソフトウェア レビュー プロセスは形式の範囲にわたって存在し、スペクトルの一方の端では「バディ チェック」などの比較的構造化されていないアクティビティがあり、他方ではウォークスルー、テクニカル レビュー、ソフトウェア検査などのより正式なアプローチがあります。IEEE 規格 1028-1997 では、ソフトウェア監査とともに、最後の 3 つのそれぞれの正式な構造、役割、およびプロセス (「正式なピア レビュー」) を定義しています[1] IEEE 1028-1997 は IEEE 1028-2008 に引き継がれました。[3]

調査研究[誰?] は、正式なレビューが非公式のレビューよりも費用対効果が高いという結論を支持する傾向があります。非公式のレビューは不必要に費用がかかることが多く (焦点が合わずに時間が浪費されるため)、発見され修復される実際の欠陥の数が比較的少ないため、正当化されない安心感が得られることがよくあります。

IEEE 1028 正式レビューの一般的なプロセス

IEEE 1028 は、「正式な」レビューの一般的な一連のアクティビティを定義しています (特にソフトウェア監査用にいくつかのバリエーションがあります)。この規格では、マネジメント レビューテクニカル レビューインスペクションウォークスルー監査など の区別が適用されます。

標準アクティビティの規定された順序は、Michael Faganによって IBM で最初に開発されたソフトウェア検査プロセスに大きく基づいています。[4]さまざまなタイプのレビューが、さまざまな程度の厳密さでこの構造を適用する場合がありますが、すべてのアクティビティは検査に必須です。

  • 0. [エントリー評価]:レビュー リーダーは、エントリー基準の標準チェックリストを使用して、レビューを成功させるための最適な条件が存在することを確認します。
  • 1. 管理者の準備:責任ある管理者は、レビューが適切な人員、時間、材料、およびツールを備え、ポリシー、基準、またはその他の関連基準に従って実施されることを保証します。
  • 2. レビューの計画:レビュー リーダーは、レビューの目的を特定または確認し、レビュー担当者のチームを編成し、チームがレビューを実施するために必要なすべてのリソースを備えていることを確認します。
  • 3. レビュー手順の概要:レビュー リーダーまたはその他の有資格者は、(必要に応じて会議で) すべてのレビュー担当者がレビューの目標、レビュー手順、利用可能な資料、およびレビューを実施するための手順を理解していることを確認します。
  • 4. [個別] 準備:レビュー担当者は、レビュー中の作品のグループ審査の準備を個別に行います。その際、「異常」 (潜在的な欠陥) がないか注意深く調べます。その性質は、レビューの種類とその目的によって異なります。
  • 5. [グループ] 審査:レビュー担当者は計画された時間に集まり、準備活動の結果をプールし、レビュー対象の文書 (または活動) のステータスに関する合意に達します。
  • 6. 手直し/フォローアップ:作業成果物の作成者 (または他の担当者) は、欠陥を修復するため、または審査会議で合意された要件を満たすために必要なあらゆる措置を講じます。レビュー リーダーは、すべてのアクション アイテムが終了したことを確認します。
  • 7. [終了評価]:レビュー リーダーは、レビューを成功させるために必要なすべての活動が完了したこと、およびレビューのタイプに適したすべてのアウトプットが完成したことを確認します。

レビューの価値

ソフトウェア レビュー (特に正式なレビュー) の最も明らかな価値は、テストや現場での使用 (「欠陥検出プロセス」) によって問題を特定するよりも早く、安価に問題を特定できることです [出典]適切に実施されたレビューによって欠陥を見つけて修正するためのコストは、テストの実行または現場で同じ欠陥が見つかった場合よりも 1 ~ 2 桁少なくなる可能性があります。[引用が必要]

ソフトウェア レビューの第 2 の、しかし最終的にはより重要な価値は、非常に欠陥の少ないドキュメントの開発においてテクニカル オーサーをトレーニングし、欠陥を助長するプロセスの不備 (「欠陥防止プロセス」) を特定して除去するために使用できることです。 )。

これは特に、作業が完了するまで待つのではなく、作業のサンプルに対して早い段階で頻繁に行われるピアレビューの場合に当てはまります。小さな作業サンプルを早期に頻繁にレビューすることで、作成者の作業プロセスの体系的なエラーを特定できます。これは、さらに欠陥のある作業が行われる前に修正できます。この作成者のスキルの向上により、高品質の技術文書を作成するのにかかる時間が劇的に短縮され、ダウンストリーム プロセスで文書を使用する際のエラー率が劇的に減少します。

一般的な原則として、技術文書の作成が早ければ早いほど、その欠陥が下流の活動やその成果物に及ぼす影響が大きくなります。したがって、マーケティング計画、契約、プロジェクト計画、スケジュール、要求仕様などのドキュメントを早期にレビューすることで、最大の価値が得られます。研究者や実践者は、バグやセキュリティの問題を発見するプロセスをレビューすることの有効性を示しています。[5]

も参照

参考文献

  1. ^ a b IEEE規格。1028-1997、「ソフトウェア レビューに関する IEEE 規格」、3.5 節
  2. ^ Wiegers、Karl E. (2001). ソフトウェアのピア レビュー: 実践ガイド. アディソン・ウェズリー。p。14.ISBN _ 0201734850.
  3. ^ 「ソフトウェアのレビューと監査に関する IEEE 規格」 . IEEE STD 1028-2008 : 1–53。2008-08-15 [2008]。ドイ: 10.1109/IEEESTD.2008.4601584ISBN 978-0-7381-5768-9.
  4. ^ Fagan、Michael E: 「プログラム開発におけるエラーを削減するための設計とコード インスペクション」、 IBM Systems Journal、Vol. 15、No.3、1976; 「ソフトウェアの設計とコードの検査」、 Datamation、1977 年 10 月。「ソフトウェア検査の進歩」、 IEEE Transactions on Software Engineering、Vol。12、No.7、1986年7月
  5. ^ Charles P.Pfleeger, Shari Lawrence Pfleeger. コンピューティングにおけるセキュリティ第四版。ISBN 0-13-239077-9