ビジネス書はこれを読もう

< 新しい記事

新着記事一覧(全1110件)

過去の記事 >

2010/05/05

ソフトウェア・レビュー技術/織田巌

テーマ： ★ おすすめのビジネス書は何ですか！？(1591)

カテゴリ：システム管理

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

【中古】ソフトウェア・レビュ-技術基礎から実践までのノウハウ/ソフト・リサ-チ・センタ-/織田巌（単行本）
価格：984円（税込、送料無料) (2025/12/18時点)

楽天で購入

ソフトウェア・レビュー技術―基礎から実践までのノウハウ

ソフトウェア・レビュー技術

第１章なぜレビューを実施するのか、効果的なレビューとは何か！
　□ レビューは静的文書とモデルを評価します。一方、テストは成果物の動作を実際に評価します。
　□ 手戻りは開発工数の40%から60%を占めると言われています。
　□ レビューがプロジェクトを遅らせるのではなく、欠陥が遅らせるという認識が必要です。

　□ レビュー時間の浪費対策
　　１）レビューに必要な資料はできるだけ早めにメンバーに配布する。
　　２）レビューアは事前検討を行い、必ず肯定的意見と否定的意見を持ち寄ることを義務付ける。
　　３）レビューではバグ発見に努め、解決はミーティング終了後に実施する。
　　４）レビューでのバグ目標を明確に設定し、レビュー完了時に目標未達の場合には、確実にフォローを実施する。

　□ レビュー実施の徹底施策

　　２）レビュー実施時間はあまり長すぎないように１回あたり２時間居ないを厳守する。
　□ レビューの主目的を認識し、共有化する
　　・不良を早期に発見し、手戻り工数およびデバック工数等の削減を図る。
　□ ソフトウェアに求められる信頼性基準
　　１）基本的な動作環境であれば必ず動作する。
　　２）マニュアル通りの動作がすべてチェックされていること
　　３）データの入力が境界条件で確認されていること
　　４）顧客がどんな操作をしてもプログラムが暴走しないこと
　　５）顧客がどんなミスをしても寛大であること

　□ 効果的なレビュー実施のための前提条件
　　１）レビューが共有されたプロジェクトにおけるビジョンを確認できるように、各プロジェクトのビジネスゴールを定義し、伝達すること

　　３）レビューおよびその他の品質向上作業が、チームの品質目標達成にどのように貢献するかを理解すること
　　４）レビューとは何か、なぜやる価値があるのか、誰が参加すべきか、どう実施するかについて、開発組織内の関係者と意識を共有すること
　　５）組織のレビュープロセスと定義と管理、参加者のトレーニング、レビューの実施、レビューデータの収集と評価などのスタッフ業務に必要な時間を確保すること。

　□ 総バグ摘出目標値の70%～80%以上をレビューで摘出し、残りをテストで摘出するという考え方が一つの例としてあります。
　□ 目標と実績の差分について、フォローを確実に行います。

　□ レビュー観点として検証と妥当性を対にして実施していくことが、現在おかれているソフト開発の市場環境で対応していく一つの手段になります。

第２章レビュー実施前に何をすべきか！（レビューの基礎知識）
　□ 作業成果物の バグを効果的に摘出 するために考慮すべき８つの観点があります。
　　１）計画
　　２）準備
　　３）記録
　　４）フォローアップ
　　５）チェックリスト
　　６）手順
　　７）基準
　　８）分析

　□ レビューの実施記録を残すことは重要な事項の一つです
　□ 新人が理解できなければバグとみなす

　□ レビュー開始基準
　　１）文書は、スペルチェック済みで校正済みであること
　　２）一連のバージョン識別子を持っていること
　　３）モデレーターが簡単に見て、甚だしい品質問題やレイアウトの誤りがないこと
　　４）未解決の問題はすべて明示されていること
　　５）先行作業成果物の品質レベルが確認されていること

　□ チェックリスト とは、以下のようなものと言うことができます。
　　１）いかにバグを発見するのかの指示
　　２）さらにバグを発見するための刺激
　　３）専門家的な役割のチェックリストによりプロジェクトの成果を増大
　　４）ルールの遂行
　　５）継続的改善のためのツール
　　６）ノウハウを展開するもの
　　７）未熟者への学習ツール

　□ チェックリストの整備方法
　　１）レビューによってチェックリストそれ自身もチェックする
　　２）バグから学んだ経験を反映して随時アップデートをし続ける
　　３）一連の質問は１ページを越えてはならない（およそ２５項目）
　　４）重大なバグを掘り起こすような質問に集中する
　　５）質問形式で記載する
　　６）考えられる質問すべてを含んでいる必要はない
　　７）新たなルールを定義するなどの間違った使い方をしてはいけない

　□ レビューア
　　１）準備を怠らない（レビューの失敗原因の８割は準備不足
　　２）言葉使いに気をつける
　　３）問題は提起するが、解決はしない

第３章どのような観点でレビューを実施するか！（レビューの実施）
　□ 設計が曖昧になる原因としては、「設計者の整理・分析や理論展開の能力不足」「精緻さや気配りの不足」などが挙げられます。

　□ 基本設計時のレビュー観点
　　１）要求品質達成度観点
　　２）実現方式観点
　　３）標準化観点

　□ 重点レビュー方針
　　１）機能性　
　　・製品仕様が明示されたものとの整合性は？
　　・他ソフトとの連携はある？
　　２）信頼性
　　・障害頻度に対する要求度合いは？
　　３）使用性
　　・設定値のカスタマイズ要求度合いは？
　　４）効率性
　　・処理量のピーク/高負荷環境/高レスポンス溶融がある？
　　５）保守性
　　・ダウン回復許容要求時間は？
　　６）移植性
　　・多国語対応/複数OSへも対応？

　□ 機能設計時のレビュー観点
　　１）正確性観点
　　２）実現方式
　　３）標準化

　□ バグの47%はシステムのモジュールの4%で発見される。

第５章レビュー結果を分析し評価する！（レビュー分析・評価）
　□ 実施段階の品質管理目標と実績による「対比表」を作成し、差異分析->傾向分析->内容分析の手順で品質レベルの判定、品質上の問題点や問題点が存在する可能性分析を行います。

　□ バグ分析 においては、作り込み過程、作り込み原因や見逃し原因の観点から分析を行い、プロダクト品質向上のための施策、プロセス改善のための施策を実施します。

　□ 施策検討 の際には、当該バグの対応のみでなく横展開が重要との観点にたって、影響範囲をよく考慮した上で実施する。

　□ 分析結果 にもリスクがあることを考慮し、観点に不足はないか、違う観点から見ても同様の知見が得られるか、などの確認を行います。

　□ 今回の開発製品のみを主体とするのではなく、開発作業（プロセス）を主体に「悪いところを計測し」、それを「改善する」品質管理のフィードバックを実施する仕組みを展開し 次回開発等に反映 していく、いわゆる継続的なプロセス改善をデータ分析に基づき実施していくことが重要です。

第６章レビューを組織的に促進する！
　□ プロジェクトレビュー観点

　　１）開発計画書立案時
　　・信頼目標、操作性目標、効率性目標の記述は具体的か
　　・計画や見積もりは妥当か
　　・品質目標の設定根拠は妥当か
　　・リスクは考慮されているか
　　・理由見解に記載された内容に不明瞭な記述や妥当性に疑問のある事項はないか
　　２）上工程完了時
　　・管理限界値外分析結果や見解は妥当か
　　・計画の見直しは必要ないか
　　・リスクに対する対策はタイムリーに実施されているか、追加施策が必要か
　　・レビューは有効に実施されているか
　　・テスト工程での品質計画に問題はないか
　　３）出荷時点
　　・出荷基準は達成しているか（性能を含む）
　　・バグ摘出状況は収束しているか
　　・予実差を分析し、分析結果および対応策は妥当か
　　・注意制限事項の致命度、回避策は妥当か