24
X 20246 : 2021 (ISO/IEC 20246 : 2017)
図B.2−ビッグ社の要検討事項ログの例
B.3.3 要検討事項ログの例−タイニー社
表B.1は,タイニー社で使用している要検討事項ログの例である。これは,システム要求仕様の“個々
人のレビュー”の一部として個々のレビュー担当者(Jean Kettles)によって作成された要検討事項ログで
ある。“状態”及び“割当て先”のフィールドは,“要検討事項の共有及び分析”アクティビティ(6.4.4参
照)で要検討事項を分析したときに入力する。
表B.1−タイニー社の要検討事項ログの例
要検討事項ログ
UV/TIT-14 33a v1.0 システム要求仕様のテクニカルレビュー
発見者 Jean Kettles 日付 2015年3月14日
ID 説明 重要度 状態 割当て先
1 指定した要素の最大数は,指定した濃度 高 未定 未定
アルゴリズムでは処理不可能である。
2 濃度アルゴリズムの結果は,小数点以下 低 未定 未定
1桁まで表示するとなっているが,利用
者仕様では小数点以下3桁が必要とされ
ている。
3 文書の改版履歴が不完全である。 低 未定 未定
4 システム仕様は,利用者要求事項内の構 高 未定 未定
成に関する要求事項(3.4.5.12)を実装で
きていない。
·
B.3.4 インシデント報告書の例−ビッグ社
表B.2は,ビッグ社で使用しているインシデント報告書の例である。インシデント報告書は,通常,ア
ジャイルチームが現在の反復内で要検討事項を処理不可能な場合,又はアジャイルチームの外部の製品又
は文書に関する要検討事項の場合にだけ作成する。
――――― [ pdf 26] ―――――
25
X 20246 : 2021 (ISO/IEC 20246 : 2017)
表B.2−ビッグ社のインシデント報告書の例
インシデント登録様式
番号 反復 10−チーム QQQ #31
表題 支払プロトコルに先頭の識別子がない。
製品/文書 ACME Web決済システムプロトコル定義(外部−ACME Payments Ltd)
状態="開始"
登録書作成者 Mike Nelson 日付 2015/01/11
重要度 高 優先度 低
総合的な説明 支払メッセージのプロトコル定義において,支払メッセージの既定動作が送信である
場合には全ての受信支払メッセージの前に%%INC%%を付けることが必須であると
いうことを指定不可能である。
状況 非形式的グループレビュー−チーム QQQ メンバー 2015/01/11
B.3.5 インシデント報告書の例−タイニー社
表B.3は,タイニー社で使用しているインシデント報告書の例である。
表B.3−タイニー社のインシデント報告書の例
インシデント報告書
番号 タイニーレビュー00233
表題 フィールドテスト期間入力欄が短すぎる。
作業生産物 UV/TIT-14 33a 利用者要求仕様
版(n.m) 1.0
状態="開始"
報告書作成者 Amir Khan 作成日時 3月14日 午前11時30分
要検討事項検出者 Amir Khan 検出日時 3月17日 午前11時00分
総合的な説明 利用者要求事項では,フィールドテスト期間の入力テキストフィールドを5文字に制
限する必要があると指定されているが,フィールドテストは99時間を超える可能性
があるため,6文字必要である。
検出作業 ウォークスルー/レビュー/インスペクション/コーディングとビルド/
テスト/利用
検出工程 要求事項/設計/実装/テスト/運用
症状 OSクラッシュ/プログラムハングアップ/プログラムクラッシュ/入力/
出力/製品全体の故障/システムエラー/他 :
利用者要求事項で,誤ったフィールド長が指定されている。これは,契約され,かつ,
スケジュールされた支払の基礎であるため,顧客が認識して修正する必要がある。
利用者への影響 高/中/低
利用者緊急度 緊急/高/中/低/なし
B.3.6 レビュー報告書の例−ビッグ社
表B.4は,試作した新規利用者登録画面で実施した非公式グループレビューのレビュー報告書である。
――――― [ pdf 27] ―――――
26
X 20246 : 2021 (ISO/IEC 20246 : 2017)
表B.4−ビッグ社のレビュー報告書の例
· 作業生産物の説明 : 新規利用者登録画面
· 参加者 : これまでに同様のプロジェクトに携わった経験豊富な3人のレビュア。
· レビュー結果の要約 : レビュアによって発見された七つの要検討事項があった
(図B.2の試作した新規利用者登録画面のハードコピーに朱筆したもの参照)。
· 作業生産物の評価 : 七つの要検討事項全てへの対処が推奨されるということがユーザ
インタフェース設計チームに伝えられた。
注記 この情報は,メール,口頭など,様々な形式で提示可能である。
B.3.7 レビュー報告書の例−タイニー社
表B.5は,システム要求仕様V 0.9(UV/TIT-14 33a用)のテクニカルレビューのレビュー報告書である。
表B.5−タイニー社のレビュー報告書の例
レビュー報告書−テクニカルレビュー−システム要求仕様 V0.9
報告日 : 2015年3月22日
レビュー対象文書 : システム要求仕様 V0.9 for UV/TIT-14 33a
ベースライン文書 : 利用者要求仕様 v 2.3 for UV/TIT-14 33 シリーズ
参加者 : レビューリーダ兼進行役 : Frank Spencer,執筆者兼書記 : Betty Fisher,技術指導者 : Tome Jones,レビュア :
Glyn Lewis,Ronne Wisdom
レビューメトリクス :
レビュアの報告によると,各自のレビューの準備は平均4.7時間を費やした。レビュー会議(全ての参加者が出席)
は110分間行われた。
レビューの要約 :
99件の要検討事項が要検討事項ログに記録された。94件を残して5件は拒否され,94件のうち2件を除く全てが
レビュー中の作業生産物に関連付けられていた。要検討事項の説明については,UV/TIT-1433a Sys Reqts Specn Tech
Review Incident Log v1.1を参照。
システム要求仕様中に,2件の重要度 : 高の欠陥が特定され,23件の重要度 : 中の欠陥と67件の重要度 : 低の欠陥
が特定され同意された(合計92件の要検討事項/欠陥)。
システム要求仕様の基礎となった利用者要求仕様について,二つのインシデント報告書が作成された(要検討事項
47及び69参照)。インシデント報告書は,Tiny Coバグ追跡システムで利用可能である。識別子 : UV/TIT-
1433aDR1717及びUV/TIT-1433aDR1718。
レビュー結果 :
システム要求仕様の要検討事項が執筆者によって対処され,レビューリーダによって完了されたことが確認された
後,設計チームが使用するために文書を発行可能であるという合意が得られた。
以上
――――― [ pdf 28] ―――――
27
X 20246 : 2021 (ISO/IEC 20246 : 2017)
附属書C
(参考)
レビュー属性
C.1 作業生産物レビューの属性
C.1.1 概要
この附属書では,レビューに適用可能な様々なレビューの属性及び特性を説明している。
C.1.2 レビュー属性
C.1.2.1 目的
作業生産物レビューの目的は,次を含むが,必ずしもこれらに限定されるものではない。
− 要検討事項(例えば,欠陥)を検出する。
− 品質を評価し,作業生産物の信頼性を確保する。
− レビュアを教育する。
− 合意を得る。
− 新しいアイデアを生み出す。
− 執筆者が改善するように動機付け,それを可能にする。
− ソフトウェア開発の時間,費用及びリスクを低減する。
C.1.2.2 役割
レビューには幾つかの異なる役割を担う様々な利害関係者が関わっている(全てのレビュー種別におい
て全ての役割を適用するわけではない。)。
− 執筆者 : レビュー対象の作業生産物を作成し修正する。
− 顧客 : 顧客独自の視点を提供する。
− 進行役 : レビュー会議の効果的な運営を確実にする。しばしば司会者と呼ばれる。
− 管理 : 何がレビューされるべきかを決定し,レビューのスタッフ,時間などの資源を提供する。通常
はプロジェクト又はプログラム管理者である。
− 読上げ係 : レビュー会議において,レビュー会議の参加者がレビュー対象の作業生産物の特定の側面
に着目するように作業生産物を準備し,(しばしば言い換えて)それを読み上げる。
− 記録係又は書記 : 個々人のレビューアクティビティで識別された要検討事項を照合して優先度を付与
し,レビューの意思決定,発見された新しい要検討事項などの情報を,レビュー会議において記録す
る。
− レビューリーダ : レビューに誰が関与するかの決定,いつ,どこで開催するかの企画など,レビュー
の全体的な責任を負う。
− レビュア : 作業生産物の要検討事項を識別する。レビュアは,対象分野の専門家,プロジェクトで作
業している人,作業生産物に関心をもつ他の利害関係者などである。
− レビュー調整役 : レビュー基盤の準備,レビュープロセスの管理,レビュー結果の継続的な分析,及
――――― [ pdf 29] ―――――
28
X 20246 : 2021 (ISO/IEC 20246 : 2017)
びレビューリーダ活動の調整を含む,組織内のレビューの運用に対する全体的な責任を負う。
− 技術指導者 : 技術的なインプットを提供し,テクニカルレビューが目的を達成したかどうかを判断す
る。
各役割のレビュー種別への関連付けを,附属書Dに記載する。
注記1 インスペクションでは,レビューリーダと進行役の役割とが組み合わされ,通常はインスペク
ションリーダと呼ばれる。
注記2 様々なレビュー種別において,一部の役割は必須,一部は任意であり,その他は他の役割と一
緒に担えない。(表D.1参照)。
C.1.2.3 個々人のレビューの手法
要検討事項を識別するために個人によって使用されるこれらの手法は,通常,要検討事項の主要な部分
を検出するため,レビュープロセス成功の基礎となる。これらの手法は,7.2で定義している。
C.1.2.4 任意のアクティビティ
箇条6に規定している作業生産物レビュープロセスの全ての部分が,全ての種別のレビューに必要とい
うわけではない。表D.1は,各レビュー種別について,どの部分が必須であり,及びどの部分が任意であ
ると考えられるかを識別する。任意の部分は次のとおりである。
− 個々人のレビュー
− レビュー会議
C.1.2.5 レビュアの人数
レビューに積極的に参加するレビュアの人数は,最適な実績を確保するために慎重に検討する必要があ
る。実績をどのように解釈するかは,レビューの主な狙いが要検討事項の識別,要検討事項の解決,情報
の伝達であるかどうかといったレビューの目的に依存する。“個々人のレビュー”アクティビティに関わる
レビュアが増えれば,通常は発見される欠陥が増えるが,欠陥検出におけるレビュアの有効性は彼らの専
門知識に大きく依存する(通常,レビュアは,おおよそ三つの欠陥のうち一つくらいは見つける。)。高度
な専門知識をもつレビュアが活用できる場合,二人のレビュアとするのがしばしば最適である。
二人以上のレビュアが選ばれた場合は,レビュー対象の作業生産物に関する異なる側面にレビュアを着
目させるよう注意を払う必要がある。そうしなければ,労力の重複(及び要検討事項の重複発生)が費用
対効果を低下させる可能性がある。
幾つかのレビュー種別では,同じ人が過度に多くの役割を担うことを避けるために,レビュアの最少人
数が決められている。
C.1.2.6 計画されたレビューの回数
単一の作業生産物に対して複数回の形式的なレビューを計画することの費用対効果が高いことはまれで
ある。しかし,最初のレビューの結果で,もう一回レビューが必要になることがある。複数回のレビュー
は,形式的なレビュープロセスが最初に組織に導入されたときに,レビューされた作業生産物の執筆者が,
以前に厳格な品質管理を受けておらず,良質の作業生産物を作成するためのトレーニングを受けてこなか
った場合に,よく発生する。
より費用の掛かる形式的レビューに先立って,最初に作業生産物のあまり形式的でないレビューを行う
――――― [ pdf 30] ―――――
次のページ PDF 31
JIS X 20246:2021の引用国際規格 ISO 一覧
- ISO/IEC 20246:2017(IDT)