SQuBok(R)分類検索
35 件の資料が見つかりました。
ダウンロード数: 2372回
紹介文 :
改善推進側の立場から、『プロジェクト特性に見合ったレビュープロセスの適用』と『レビュー成熟度に応じたレビュー改善』を客観的な診断に基づき推進する手法を提案している。また、その診断を各プロジェクトが簡単に自己診断できるためのツールも開発しており、プロジェクトが自立的にレビュー改善を推進できるように工夫されている。
ダウンロード数: 1776回
紹介文 :
プロジェクトの状況・内容・特性を把握し、そのプロジェクトにとってレビューの効果を最大限に発揮することを目的として、研究論文や書籍、SQiP研究会や各種勉強会、各研究員の現場での実践事例など、様々な所で語られているレビューにおける戦略の手法をレビューの計画・準備・実施・振り返りのプロセス毎に整理して「レビュー戦略マニュアル」にまとめている。レビュー戦略の立て方など具体的な事例が書かれており、実用性を考えた内容になっている。
ダウンロード数: 1768回
紹介文 :
各設計工程での手戻り削減と開発計画遵守を目的として、レビューを早期に実施する手法「TPR(TriPartition Review)」を提案している。 早期にレビューを実施するレビュー手法は過去にも提唱されているが、TPRは、各設計工程の期間を大枠・詳細・総合の3つのフェーズに分割し、各フェーズ終了時点の3回で、予め用意したレビュー観点表を用いてレビューを行うという手法で、レビューの実施時期とレビュー観点が決まっているので誰でも効果が得られるという点が特徴となっている。
ダウンロード数: 1587回
紹介文 :
仕様書のレビューをする際のレビューの観点を何にするかは,しばしば議論されている.本論文では,結論として,たとえそれを書いた設計者であっても,機能仕様書を作った後に思考をリセットしてテストエンジニアの視点(懐疑的な観点)を持ってレビューを行えば,効果的な結果を得られたことを示している.逆に,テストエンジニアが機能仕様書を書いても,設計者が書いたものと同様な欠陥を出していることを実験で示しているのが面白い.レビューの観点について考えさせられる論文である
ダウンロード数: 1567回
紹介文 :
レビューアには、様々な能力が求められるが、その中でも特に重要な能力とは何か、そしてその能力を向上するための良いトレーニング方法は無いか。 本論文では、重大欠陥を素早く検出するために特に重要となる能力のトレーニング方法を考案している。 新聞の社説を用いたシンプルかつ短時間で取り組める内容のため誰でもすぐに実践でき、効果も期待できそうなので、自分もやってみようと思える内容になっている。
ダウンロード数: 1467回
紹介文 :
要求仕様書の品質を上げるための施策を3つ提案している.一つはWモデルの考えで,要求仕様書とテスト設計書を同時作成し,テスト設計書から要求仕様書にフィードバックをかけるとうもの.もう一つは,仕様書にハイパーテキストを使って,仕様書間の矛盾を発見しやすくしたもの.最後は,記載漏れを防ぐためのチェックリストを提案している.
ダウンロード数: 1343回
紹介文 :
レビューでよくつかわれるチェックリストは絶えずメンテナンスをしていかなければならない。本論文は、効果的なチェックリストを作るために、ベテランエンジニアの暗黙知を導入する方法を提案している。
ダウンロード数: 1333回
紹介文 :
認知心理学・社会心理学の理論「認知バイアス」をご存知だろうか? 「曖昧性効果」「専門偏向」「共有情報バイアス」「ゼロリスクバイアス」「アンカリング」など、193個の定義があるが、その中から、ソフトウェア開発の現場で作成者が掛かる可能性が高く、かつ、その影響度が高い13個に絞り込み、レビュー時の欠陥検出に活用する方法が提案されている。 レビュー対象成果物への記載漏れや考慮不足といった検出難易度が高い欠陥をどうやって検出すれば良いのか悩んでいる方は、一読されることをお勧めする。
ダウンロード数: 1221回
年度 : 2012年   分科会 :
紹介文 :
アジャイルプラクティスを教育の場としながらも品質を確保する取り組みの事例紹介です。課題設定とアプローチ、その実施結果が明瞭にわかりやすく表現されているでとても参考になります。
ダウンロード数: 1188回
紹介文 :
レビュー担当者のスキルおよび欠陥の種類の違いによって、レビュー手法の有効性にどのような影響を与えるのか、その関係を実験により明らかにしています。実験結果では、ユーザやテスト担当者などの観点別に行うレビュー手法が (Perspective-based Reading: PBR)、経験や知識がない人でも,高い精度で欠陥が検出できることが示されています。
ダウンロード数: 1079回
紹介文 :
現状アジャイル開発でウォータフォールと同じような品質保証活動を行うと、過大な工数がかかるか、品質保証活動が開発の終盤になってしまう。 この課題を解決するために、品質保証部門のみによる監査ではなく、開発現場自身がセルフチェックを行うことで相乗効果を狙うアプローチを「QAAD42」(Quality Assurance in Agile Development by 42)と命名し検証を実施し、その効果を確認した。
ダウンロード数: 1035回
紹介文 :
レビュー会議が時間通りに終わらない、効率的なレビュー会議にするためにはどうすれば良いか。 本論文では、レビュー会議での発言内容毎の時間を測定し、どのような発言がどの程度行われているのかを可視化することで、レビュー会議の参加者間で会議の目的に微妙なズレがあることを認識させ、レビュー会議の改善を促す手法を提案している。 時間というのは、その人の置かれた立場や状況の違いによって感じ方が異なる一方、絶対的で普遍的な指標とも言えるため、レビュー会議の現状把握や分析を行う際に大いに活用できそうである。
ダウンロード数: 993回
紹介文 :
上級レビューアの欠陥検出テクニックの1つ『欠陥情報をパターン化して蓄積した「欠陥パターン」とレビュー対象を照合して、欠陥混入箇所と欠陥内容を推測することで、素早く且つ高い精度で欠陥を検出する方法』を、初級・中級レビューアも活用できるように、欠陥パターンに一般的に知られている欠陥検出テクニックを紐づけたレビュー手法『DPDT法』を考案している。 また、手法の提案に留まらず、実践で活用できるようにするために、反復練習型トレーニング教材「チョコ・トレ」も開発されている。 この学習教材はレビューアだけでなく、仕様書作成者にとっても非常に有用なものとなっている。
ダウンロード数: 842回
紹介文 :
レビューの重要性/技法の解説は一般的に普及しているが、レビュー担当者の必要教育/育成に関する書籍・論文は極めて少ない。また、体系的な技術教育としての学習範囲/分類のまとめみならず、品質担当者育成の段階的教育/経験・キャリア別の育成に関する方針書としても、「心構え」といった観点を加えて解説している点が特筆に値する。 企業の品質教育の一助として価値がある。
ダウンロード数: 808回
紹介文 :
レビューで重大な指摘をしても、修正されなければ意味がない。 本論文では、レビュー指摘を作成者に抵抗感なく伝えるための手法を提案している。 プロジェクトや作成者の状況などを配慮せず指摘を伝えてしまうと、作成者は抵抗感を抱き、指摘を素直に聞こうとはしない。 特に第三者レビューを実施している人は、悩まれているところだと思うので、一読頂きたい内容となっている。
ダウンロード数: 693回
紹介文 :
トップレビューアの頭の中がのぞけたら・・・本論文の研修者たちは挑戦した。トップレビューアの思考プロセス、それがHDR法だ。もしこの方法で優秀なレビューアが育つなら試してみない手はない。悩みを抱えるPMや品質管理部門の方はぜひご一読をお勧めする。
ダウンロード数: 674回
紹介文 :
本研究は継続的にレビューする手法ContinuousReviwについて記すものである。レビュー品質の向上を目指すうえで、「短時間、レビューアのばらつき」の問題は大きい。CR法はプロセスを持つレビュー法であるが、参加者自身がレビューの目的とルールを定め、振り返りを行い、新たなレビュー観点やルールの変更を検討する。特にレビュー期間が限られているプロジェクトの品質担当者にご一読いただきたい。
ダウンロード数: 519回
年度 : 2012年   分科会 :
紹介文 :
曖昧な表現によってソフトウェアに欠陥が作り込まれており、これらをレビューで見付けるにも限界がある。そこで社外の過去の研究成果をベースに曖昧な表現を機械的に検索できるチェックツールを開発し、レビュープロセスに組込んだ活動発表です。 レビュー前の仕様書に適用し、問題点が抽出出来ており、効果もあることが確認されています。
ダウンロード数: 504回
紹介文 :
現場での課題の分析結果から、レビュープロセスを改善しています。具体的な手順や帳票も提案されており、すぐに現場で活用することが可能です。また、レビューの真の目的は「ソフトウェア品質に対する不安を除去すること」との認識から、不安ヒアリングシートという帳票が開発されており、ユニークな発想で興味深いです。
ダウンロード数: 501回
紹介文 :
ドキュメントに敢えて記載されることがない暗黙的な情報(ステルス情報)を、レビューの場に引き出し活用することで、認識齟齬や漏れに起因する重大な欠陥を検出するレビュー手法『SBR法(ステルス・ベースドレビュー手法)』を考案している。 ステルス情報を、所有者(ユーザ、プロジェクト、作成者)と、種類(状況、知識、経験)で掛け合わせたマトリクスで整理したり、レビュー対象のプロジェクト特性によってパターン化したり、具体的な引き出し方法についても工夫されている。
  

1

2
↑