紹介文 :
アジャイル開発の品質保証における製品品質を評価プロセスの改善提案である。開発途中にプロセスゲートという評価マイルストンをおいて品質をみえる化し、それを積み上げていくことで、製品品質の品質保証のための評価法を提案している。

紹介文 :
ソフトウェアのメンテナンスフェーズを対象とした欠陥の分析や予測は、新規開発と並んで重要である。また、現状のメンテナンスフェーズにおける品質関連の研究の多くは、残存欠陥の「数」に着目したものである。

我々は、残存欠陥の検知数には何らかの周期的な変動があり、その変動要因を知ることができればソフトウェア欠陥の発生傾向の分析や予測につなげることが出来るのではないかと考えた。しかし、それを裏付けるような研究は行われていなかった。

そこで我々は、実際のプロジェクトにおける欠陥検知数の特徴的な変動から周期を検出し、それに基づく要因分析を行うことによって、ソフトウェア欠陥の発生傾向の分析や予測を可能にする手法である「CDAM（Cyclic Defect Analysis Method）」を考えた。

本発表では、CDAMの詳細について実例を交えながら報告する。その上で、欠陥検知の周期性と変動要因を認知することで可能になる、ソフトウェアの品質向上のためのアプローチを提案する。

紹介文 :
弊社では、大小さまざまな種類のサービスが急激な拡大や変化を繰り返しており、またその運用フェーズでは恒常的なエンハンスが発生し、それに対しての品質保証（QA）業務が発生している。そのようなサービスの急激な拡大・変化に伴い、QA業務を担う我々の部門の人員も急速に増加している。
そして、それら人員の多くは、テストベンダから派遣されたメンバで構成されており、またプロパーのメンバはそのようなQAメンバのマネジメントが業務の一定の割合を占めている。そのようなテストベンダからの急速な人員増加に伴い、技術・マネジメント領域を問わず様々な問題が発生するようになった。

本取り組みではマネジメント領域に焦点を当て、QA業務とQAメンバのスキルがマッチしない問題やQAメンバのモチベーションに関する問題を取り上げ、その解決のためにまずQAメンバのスキルレベルをテスティングロールとして定義した。この定義において、テスト業務を遂行する上で必要な業務要素をテスト技術・マネジメント技術の両面から洗出し、４つの技術領域の枠組みを定め、その枠組で業務要素を整理した。次に、テスティングロールに基づきQAメンバのアサイン・QAメンバのモチベーションという観点で活用法を検討し、実際に2年以上の運用を行った。

本発表では、以上の取り組みに加えて、2年以上の運用を経たテスティングロールの有効性を評価するために実施したアンケートの結果についても報告する。

紹介文 :
ソフトウェア開発で行われるようなプロジェクトの完遂までに生じる諸問題を検討するタイプの会議を対象として考える。ステークホルダーは会議を開き、議論を通して現状を認識し、問題に対する合意形成を行う。

しかし、我々はその会議において参加者は想起した自分の意見を必ずしもすべて発言という形で表出しないのではないかと考える。例えば会議中に持っていたものの結局発言されなかった意見や会議終了後に思いついた意見など、それらの意見は発言を記録する議事録には記録されていない。しかしその発言されなかった想起のもととなった意見や疑問も消えてしまったと考える理由はない。いつかもう一度想起されて表に出てくる可能性がある。次の会議か次の次の会議かもしかして成果物が出来上がってなにか問題が発生してから思い出されるその意見は、時間やコストを消費し、成果物の機能や特性に影響を及ぼすものであったかも知れない。

記録されなかったために問題として認識されず、議論もされなかったために問題は潜在化したままになったのである。我々はこの問題を解消するためには、まず会議で参加者が想起した意見をそのタイミングで収集して記録する必要があると考える。我々はMinute Paperと呼ばれる質問紙でそのような意見が記録できるか実験を通して確認し、それをフィードバックすることで今後の議論に含めることができるか検証した。

紹介文 :
アジャイル開発のスクラムフレームワークにおける要求プロセスにおいて、もっとも要求の品質にかかわるアクティビティの一つがリファインメントです。この論文は、要求における問題で手戻りになる問題がリファインメントのやり方にあることを認識し、実用性のある改善の方法を提案している。いままで、リファインメントの課題や改善について議論されている文献はほとんどなく、新規性を持った論文である。

紹介文 :
本研究は、品質保証メンバーが客観的役割を基本としつつ、品質保証活動より得られた知見を活かして、開発プロジェクトに積極的に寄り添ってQCD 問題解決を促進する活動の提案である。
調査分析から、開発プロジェクトが品質保証メンバーに期待する支援範囲を抽出し実践した、大変有用性の高い研究である。

紹介文 :
アジャイル開発の品質保証における製品品質を評価プロセスの改善提案である。開発途中にプロセスゲートという評価マイルストンをおいて品質をみえる化し、それを積み上げていくことで、製品品質の品質保証のための評価法を提案している。

紹介文 :
AI/IoT時代の新しい安全分析手法として注目されているSTAMP/STPA (Systems Theoretic Accident Model and Processes / System Theoretic Process Analysis)は、セーフティとセキュリティのリスクを同時分析が可能であることを本分科会では昨年度、初めて提言しました。今年度はSTAMPを用いた場合と用いない場合に分けて、自動運転の利用シーンを具体化した事例による実験を実施し、STAMPによるセーフティセキュリティ分析の有効性を確認しました。
論文とともに具体的な分析の一連の証跡、分析手順、実験の質問事項や結果、用語集など、利用価値の高い付録も収録しています。ぜひご活用ください。

紹介文 :
レビューの品質を第三者が評価して必要に応じて対策を促すことを目的とした「レビュー品質の可視化手法」および新しい品質指標「予測重大欠陥レビュー検出率」を提案しています。
第三者が客観的かつ容易に、そして各プロジェクトの特性を踏まえてレビュー品質を評価出来るように工夫した研究です。

紹介文 :
設計を開始する前に要求の漏れを検知し手戻りを抑制することを目的とした「設計着手前レビュー」を提案しています。
「着手前要求確認フレームワーク」と「区分・パラメータ」シートを考案し、
5W1Hの観点で要求を整理し抜け漏れを検知しやすくするための工夫をしています。

紹介文 :
レビュー指摘の伝達において、指摘の意図や期待を作成者に上手く伝えることを目的として、「レビューコミュニケーションスタイル手法」を提案しています。
人と人とのコミュニケーションにおいて「人の好みや性格」といった重要とされつつも取り扱うことが難しかった領域に踏み込み、具体的に理論化・手法化してレビューで活用できるように工夫しています。

紹介文 :
本論文では、派生開発において高リスクな不具合を早期に検出しやすくするため、従来のリスクベースドテストよりも軽量なテスト手法を提案している。
具体的には、新旧ソフトウェア間における機能群単位でのテストケース数の変化割合および不具合の検出数からテスト実施の優先度を付ける手法（LightTest-Prioritization Method，LTP-Method）である。これらの情報はプロジェクト情報として揃う情報であるため、テスト実施のために新規で揃える必要がない。これらの情報を説明変数として重回帰分析を行い、高リスク不具合の潜在期待値を機能群ごとに導き出すことで、テスト実施の優先度をつける。
本手法は従来のリスクベースドテストよりも導入しやすくなるため、高リスクな不具合を早期に検出できることが見込まれる。

紹介文 :
本研究は、開発プロジェクトが抽出した多数のリスクに対して、リスクを産む要因となるリスク事象ドライバーに着眼することで、品質部門がリスクの繋がりを分析（多変量解析によるモデル化）し、妥当性と網羅性の観点でレビューして、開発部門が見落とした可能性のあるリスクや軽減策を提案する、大変有用性の高い研究である。

紹介文 :
本論文では、派生開発での回帰テストにおいて、デグレード不具合を効率よく検知するため、テストケースにソフトウェア変更の影響範囲を基にしたスコア付けを行い、テスト実施するテストケースの選定手法を提案している。
具体的には、データフロー図(Data Flow Diagram, DFD)を用いてデータフローを介して繋がる機能数を機能ごとに計測し、その数を基にスコア付けを行い、スコアの高い順から優先的にテストケースを選定する手法である。
この手法により、変更後の機能からの影響を受けやすい機能をスコアとして表すことができる。そして、スコアが高い機能を優先的かつ重点的にテストを行うようにテストケースを選定することで、デグレード不具合を検知しやすくなることが見込まれる。

紹介文 :

紹介文 :
セキュリティ対策など、優先度の高い対応をスピーディに行う場面では、使用性への配慮が不足しがちです。その結果、業務効率を悪化させることが開発終盤や納品後に判明し、手戻りの要因となっています。このような問題を、顧客のビジネスリソース(作業分担，システム連携，作業自動化の程度など）の違いに着目し、解決しようとしています。チェックリストで注意を促す古典的なやり方との違いは、顧客と自社のビジネスが両立する仕様決定を促す点です。

紹介文 :