紹介文 :
Pair-wise法を適用するにあたって必要となる因子・水準・制約を、論理的に導出する方法を提案しています。これらがツリーとしてモデル化されることからレビューが容易になり、思考の過程も蓄積されるという長所があります。さらにそのモデルからテストケースの抽出にまでつなげているところもポイントです。

紹介文 :
自動テスト支援ツールの選定は誰でもが悩む問題です。この事例紹介では、性能測定テストや回帰テストといったテストの種類によってどういったツールを選定すべきかを実践して結果をまとめています。「WSH」、「UWSC」、「TestComplete」、「UIAutomation」を選定候補としています。これらのツールを使用されている方、使用を検討されている方は参考になります。

紹介文 :
メカトロニクスの分野では、新規開発の比率が高まりつつあり、不確実性が高いことが問題になっています。
本発表では、反復開発プロセスを適用する際の課題を整理したうえで、スクラムやTDDといったプラクティスの導入、CIの適用など、具体的な解決策を整理しています。ソフトウェアとハードウェアでチームが分かれているという特性から、スクラムを修正して適用しており、導入しやすい形にしているのが特徴です。

紹介文 :
2013年SQiP Best Presentation AwardとSQiP Best Paper Future Awardを同時受賞しています。レビュー熟練者の頭の中を写し取るという試みが書かれています。レビューがうまくなってくるといわゆる「匂い」というものが感じられるようになってきますが、それを「兆候」→「仮説」→「仮説検証」という形で説明しています。日頃のレビューの中で、このような考え方で進めているのだなということを再認識させてくれる内容になっています。ただ、「匂い」そのものについては軽く触れているだけなので、これ以上は実践して経験を貯めていくしかないのかもしれません。

紹介文 :
ている。このことは、開発から納品までの工期が短い「短納期型開発プロジェクト」でも同様であり、短い工期中に発生するテストの手戻りは大きな負担になる問題がある。我々はこの問題の解決策として、FaRSeT（Flexible and Rapid Software Test）というテスト手法を提案し、SQiPシンポジウム2018にて発表した。
FaRSeTを用いた探索的テストにより、事前にテストケースを準備する必要がなくなり、仕様変更が多い部分の手戻りを解消することができた。また、重要な探索箇所についてステークホルダの合意を得ながら優先して探索的テストを実施できるようになり、テストの効率化を図ることもできた。
しかしながら、以下2点の問題点が浮き彫りとなった。
? 未実施のテストは不具合が発生していないため、重要な探索箇所として判断できない。
? 不具合数だけでは、残存不具合を想定することができない。
これらの問題点により、重要な探索箇所を判断するための根拠が欠けるため、ステークホルダに探索箇所の合意を得る際の障害になっている。
そこで本研究では、これらの問題点を解決するために、重要な探索箇所を推測し、それを提示する手法「FaRSeT-#（ファルセットシャープ）」を提案する。重要な探索箇所を判断するための手法として、機械学習の1つである自己組織化マップ（Self-Organizing Maps）を利用し、セッションを二次元マップ上に可視化し提示する。

紹介文 :
１つの変更要求が及ぼす影響というのは時として他システムに跨ることもあります。この影響範囲を特定する方法として派生開発で使用されるXDDPを採用しました。
変更依頼を要求と仕様の階層構造で表現し、要求レベルで他システムへの影響を検討することで影響範囲を特定しようとした試みです。

紹介文 :
ソースコード品質評価にドメインの特性や開発者の意図を反映させ、より適切な評価結果を得る方法を提案しています。
測定されたメトリクスに対する開発者へのヒアリングの流れや結果、得られた評価結果の分析、ツールの改善点などが示されています。ソースコード品質評価における課題や改善の進め方に興味がある人にとって有意義な内容となっています。
本研究に登場する既存のソースコード品質評価ツール「Adqua」を使っている方にはもちろん、他のソースコード品質評価ツールを使っている方にとっても、参考になる研究です。

紹介文 :
工程毎に分業化された複数のグループで同時並行で行われる小規模な派生開発における進捗管理の課題に対して「機能-作業マトリクス」という簡潔な進捗管理方法を提案している。「機能-作業マトリクス」では、進捗管理時に課題となりやすい計画立案、進捗情報入力、対策立案に対して属人的な計画にならず進捗管理負荷が軽減されるように工夫されているのが特徴で、ガントチャートのように専用ソフトウェアがなくても管理可能な点が負荷軽減の一助になっていると思われます。

紹介文 :
レビューアとして自分の指摘の有効性は気になるものです。いかに短時間に重大な欠陥を指摘できるかはレビューアの腕といってもいいでしょう。本論文はビジネスリスクから有効なレビュー観点が導き出せるかを試しています。基本的にはビジネス要求からレビュー観点までをFTAに似たツリー方式で分解し、実際のレビューにその観点を持ち込むかどうかの判定はリスクベースドテストの考え方で行っています。特にレビュー初心者のアドホックレビューを防ぎ、レビュー全体の底上げ手段として有効です。

紹介文 :
大規模なパッケージソフトウェアの開発における、テスト用のデータベースのデータ品質保証をテーマとしています。開発環境やテスト環境の運用に関心が有る方に、特にお薦めです。
研究対象の開発やテスト環境の規模が数値で具体的に示され、また、改善前の問題や実施結果が判りやすくまとめられています。大規模開発の経験はないが今後取り組もうとされているに方も、読み進めやすい内容になっています。

紹介文 :
XDDPとSCRUMを組み合わせることにより、①後戻りに関する課題(終盤でのH/W変更リスク)、②人とチームが成長するチームビルディング、③ソフトウェアのリリースタイミングといった課題を解決した事例です。プロジェクトメンバへのアンケート結果もあり、現場からの声も一部紹介されています。

紹介文 :
「人間中心設計」（ISO9241-210)でのシステム開発事例およびシステム評価の事例である。要求分析としてペーパープロトタイプを使用しユーザビリティを重視した画面作成し、「構造化シナリオ」により複数のシナリオを作成している。また評価では2つのペルソナを利用し、システムの評価を行ない、重要・緊急の課題などの検出に効果があったと報告されている。ユーザビリティが重要とされるシステムに関わっている、検討しているという人にとっては参考になる報告だと考える。