IEEE729-1983仕様
（生産などのドキュメントのさまざまな段階を含む、コード、）ソフトウェアプロジェクトの正式な会合の成果でレビューと承認のためのソフトウェア製品の部門のユーザー、顧客やスタッフに提示。目的は、ソフトウェア製品、開発、保守、環境の適用の設計上の欠陥の品質に影響を与える可能性がある領域を特定するため、および是正措置をとることだけでなく、パフォーマンス、セキュリティ、経済面での可能な改善を特定することです。
レビューの目的
高品質のソフトウェア製品とプロセス改善の賛成で、ソフトウェアの開発とテストのすべての段階で適切なチェックを行います。
レビュー段階
要件レビュー
「ソフトウェア要件」
「テストの要件」
デザインレビュー
「概要設計」
「詳細設計」
コードレビュー
「コード規範」
テストレビュー
「テスト計画」
「テストケース仕様書」
「不具合レポート仕様」
定義
レビューの登録基準
審査チームリーダーが任命されました。
認定は、関連する計画で定義されています。
製品をレビューする準備ができています。
訓練を受けた評価者は、手順を確認してください。
評価者は、スキル評価の質問に訓練する必要があります。
コーディネーターは、レビューを行う方法で正式な訓練を受けている必要があります、またはいくつかのレビューの経験に参加すべきです。
「プロジェクト計画は、」開発されました。
ピアレビュー
作業成果物の同僚によって作成されたソフトウェア作業成果物を確認し、製品の欠陥、および正しい欠点を識別します。
ガイドライン：
（設計者が任意の圧力を持つことはできません）製品ではなく、見直しのデザイナーを確認します。
会場には、良い雰囲気を持っています。
リミット議論と反論（認定評議会の問題を解決するために、問題を見つけることがありません）。
むしろ言及した問題を解決するよりも、問題の範囲を指定します。
（好ましくは黒板と、黒板に書かれた任意の時点での問題）レコードを表示します。
ミーティングの数が評価中に5-9人のグループで良いはずです。
評価者のグループは、評価に含まれるべきである場合には、ピアレビューの産物です。（このようなプログラム設計書レビューとして、レビューアが他のプログラマを含める必要があります）。
パネラーグループは、上流と技術の製品の下流含むべきときに見直されます。（文書のプログラミングのEgのレビューは、レビューアはデザイナーやコーダーの詳細なフォローアップを含める必要があります）。
元付着は仕事への準備が整います。
すべてのレビューのために必要な訓練。
マネジメントレビュー
/プロジェクト管理活動中のプロダクトマネージャーは、ソフトウェアプロジェクトの評価によって欠陥識別処理を行って、管理活動を向上させます。
ガイドライン：
（設計者が任意の圧力を持つことはできません）製品ではなく、見直しのデザイナーを確認します。
むしろ言及した問題を解決するよりも、問題の範囲を指定します。
審査に必要な訓練を受けていレビュアー。
査読は、評価製品の分野で豊富な経験を持っています。
シングルレビュー
単純な作業成果物のための単一の投稿、不良品の識別、正しい欠点によって評価されます。
ガイドライン：
状況の全体的な評価とプロジェクトの進捗状況。
グループ内の人員の進行状況を評価します。
プロジェクトの品質管理状況の評価。
問題プロジェクトの進捗状況を評価する際に遭遇し、解決策を提案します。
現在存在してプロジェクトのリスクの評価。
その他の場合の評価（プロジェクトの段階に応じてもよいです）。
一般的な手順の見直し
評価計画を策定
認定の準備
検討会
評価結果に対してアクションを実行するには
審査の結果は、完了まで追跡します
提出およびアーカイブ
間違いのレビュー
参加者は、審査を理解していません
プロジェクト計画の見直しを予定していません
問題の解決策を議論する会議のレビューはなります
評価作業の十分のレビュアーは、事前の知識
レビュアーは非本質的な問題に集中し、
組織の詳細を無視
会議の時間が長すぎます
リスク分析
あまりにも多くの悲劇的な歴史は、リスクがそれを制御するために学ぶことはありません、それは確かに制御される、どこにでもあることを教えてくれる。
リスク分類
あまりにも多くの悲劇的な歴史は、リスクがどこにでもある、ということを教えてくれる、それを制御するために学ぶことはありません、それはなりますその管理下にあります
ソフトウェアのリスク
このリスク分析は、テスト、テストに何をしたいソフトウェアを決定する主要な優先順位、デプステストです。
計画リスク
このリスクは、計画外のイベントのプロジェクトのスケジュールに影響を与える防ぐために主にあります。たとえば、テスト担当者の突然の出発は、変更人員不足やソフトウェアの突然の需要につながりました。
リスク分析プロセス
「ブレーンストーミング」グループの形成。
すべての機能リストのソフトウェアの一覧を表示します。
機能不全の可能性を決定します。
衝撃による機能障害を決定します。
定量化。
計算されたリスクの優先順位。
レビューと量子化された値を変更します。
機能が優先されます。
することを決定した「リスクがラインを割ます。」
リスクを軽減するための措置を決定します。