紹介文 :
ソフトウェアの欠陥が市場で顕在化した場合、その欠陥の修正にかかる費用やＣＳ低下のリスクが大きい。このリスクを低減するために、開発中にできる限り欠陥を取り除いておく必要がある。
本論文は、出荷後の欠陥摘出の有無とプロダクトメトリクスとの関係に着目し、開発中の欠陥を取り除くプロセスとしてこれらの関係が活用できるか、日本電気株式会社と共同で実製品のデータを用いて分析を行った。
具体的には、ソースコードの有効行数と最大ネスティング数にしきい値を設定することで、しきい値以下としきい値を超えるグループで層別を行い、出荷後の欠陥摘出率に差異があるかの確認を行った。結果は、しきい値以下のグループよりもしきい値を超えるグループの出荷後の欠陥摘出率が高くなる傾向にあることが確認でき、プロダクトメトリクスがしきい値を超えるソースコードについては、開発プロセスにおいてより注意を払う必要があることを確認した。
上記を踏まえ、開発プロセスへの具体的な適用施策として、有効行数のしきい値を150行、最大ネスティング数のしきい値を4に設定すること、しきい値を超えるソースコードに対しては、しきい値以下のソースコードよりも注意深くレビューする、あるいはリファクタリング等を行うことを結論付けた。
本論文は、上記結論への導出過程を紹介する。

紹介文 :
システム開発において、外部仕様書（要件定義書や外部設計書）の品質は、後続の成果物の品質やその作成に要する工数に多大な影響を与える。しかし、実際の開発では外部仕様書の作成やレビューに使える時間は限られており、外部仕様書のエラーを完全に除去することは現実的ではない。そこで、作成した外部仕様書が次工程の作業開始に問題ない品質を備えているかを系統的かつ簡便に評価する方法が求められる。本論文では、ファンクションポイント法（FP法）の計測観点にもとづき、外部仕様書の品質を定量的に評価する手法を提案する。提案方法では、“外部仕様が確定していればFPの値は一意に決まる”というFP法の原理を応用し、FPの値が一意に決められない記述は外部仕様が確定していないと判断する。またそれらをもとに、外部設計完了時点の外部仕様書に求められる情報量を100％の満点とした『外部仕様の確定度合い』を算出する。実際のプロジェクトに適用した結果では、外部仕様の確定度合いが高いプロジェクトほど、プロジェクトの実績が良いことがわかった。本手法を用いることで、外部仕様書の品質を系統的かつ簡便に評価でき、外部仕様が確定していない改善すべき箇所も明確にできる。

紹介文 :
ソフトウェア開発における欠陥の情報は，多くの組織で蓄積されている．
混入し得る欠陥を予測し，欠陥の混入・流出を防止するためには，この蓄積された欠陥情報を活用することが不可欠である．
本研究では，欠陥の混入を予測するためには，欠陥が混入するメカニズムを理解し，欠陥を引き起こす要因を検知する必要があるということに着目し，その方法を検討した．
本発表では，欠陥の予測を目的とした，欠陥混入メカニズムのモデリング手法と欠陥データベースの構築・利用手法を提案する．

紹介文 :
テストケースの実行順序は、しばしば勘や経験に依存して決定されることがあるが、そのような場合にはブロッカーバグがテスト実行の後期に発見され、その
修正待ちによりテスト実行が遅延するといった問題が発生する可能性がある。こうした問題を経験に頼らず解決するには、自動的にテストケースの優先度付けを行うことで実行順序を最適化し、深刻なバグをより早期に発見できるようになることが望ましい。
また、ソフトウェアテストの外部委託市場は世界的にも拡大が予期されているが、そうした第三者テストにおいてテストはしばしばブラックボックスに実施さ
れる。しかしながら、ブラックボックステストにおいてテストケースの優先度付けを行う方法は、最適化に利用できる情報が限られていることもあり既存研究に
おいて充分に明らかではない。
そこで我々は、過去の類似プロダクトにおけるテスト実行結果を利用し、新規プロダクトにおいてブラックボックスに実施される単体・結合テストのテストケースを蟻コロニー最適化を用いて優先度付けする枠組みを提案する。なお、本件のアイディアはICST 2015において発表済みであるが、それに加え本稿では未
発表である、実験において手法を実プロダクトへ適用した際の工夫および結果の詳細について報告を行う。

紹介文 :
近年のソフトウェア開発は巨大化を続けており、それをサポートするように自動化ツールも普及してきている。そして、そのようなツールを使用してテスト自動化を行う組織も増えてきているが、当初期待していたような十分な効果が得られず取り組みを諦めるケースも発生している。
そのような状態に陥るのは、テスト自動化を行う際の注力すべきポイントが見つからないうえ、成功したとしても他者に事例を伝えるコストが高くつくからであろう。
そこで、このような問題を解決し、継続してテスト自動化の取り組みをサポートし続ける共通言語として「テスト自動化パターン言語」を紹介する。

紹介文 :
ソフトウェアの品質を測定するために，ソフトウェアテストを行うことが一般的だ．また，一般的にテストの品質を測定する方法として，テスト網羅率，つまりカバレッジを使用する．しかし，カバレッジが100%でもバグが検出されない例があるように，テストの品質をカバレッジのみで測定するのでは不十分な面がある．そこで注目されている手法として，「ミューテーション解析」と呼ばれる手法がある．
ミューテーション解析とは，テストのバグ検出能力を評価する手法で，ソフトウェアに意図的に加えた改変をテストが検出できるかどうかを検証する．加えた改変のうち，検出できた割合をミューテーションスコアと呼ぶ．ミューテーション解析を行うことで，これまで数値化できていなかったテストのバグ検出能力を数値化することが可能となる．これをうまく使うことでカバレッジだけでは不十分であったテストの評価能力の向上が見込まれている．
本発表では，ミューテーション解析の説明，実際に作成したミューテーション解析ツールをGitHubのプロジェクトに適用した結果，そして実用に向けての考察を行う．

紹介文 :
設計書が完成した時点でのみ実施するレビューでは,たとえレビューで適切な指摘ができたとしても,重大な欠陥が発見されると,その修正に大きな手戻りが発生する.また,残りの期間ではリカバリできない等の理由から,レビューによる是正効果が完全には発揮できていない問題がある.
その解決のために,我々は 3 分割レビューを提案する.3 分割レビューとは,各設計工程の期間を 3 分割し,1/3 時点,2/3 時点,3/3 時点の3回（以後「完成時点」と記載）で予め用意したレビュー観点表を用いてレビューを行うことで,手戻り工数削減,開発計画の遵守を実現させるためのレビュー手法である.
本提案の有効性を,基本設計工程の 1/3 時点レビューの実験より検証した.工程の 1/3時点であっても,設計の根幹に関わる重大欠陥の検出は可能であり,手戻り工数の削減,開発計画の遵守の 2 つの課題からも有効であるということを確認した.
また,プロジェクト特性に基づくレビュー観点表の具体例を複数作成し,現場適応性を高めた.

紹介文 :
ソフトウェアのテストは設計段階に作成した仕様書をベースに実施されるテストが多くの割合を占めているが、市場不具合の多くは仕様書記載外の問題に起因して発生している傾向が見えている。

我々の事業部では設計・コーディング・テストなどの開発作業を実施する開発部署とは独立した組織として品質保証部があり、開発部署の全工程完了後に出荷可否の判断として最終的な製品検査を実施している。

実際の製品検査で摘出された問題点をみたところと、仕様書記載外の問題点が多く摘出されているが、テスト項目自体は仕様書ベースのものが大半を占めていた。
以上から、仕様書ベースのテスト項目であっても、偶発的な何らかの条件が加わることで、仕様書記載外の問題点を摘出できているのではと考えた。

そこで、製品検査で仕様書記載外の問題を摘出したテスト観点やテスト項目の分析を実施した。
その結果、仕様書記載外の問題を摘出するためのテスト観点として設計段階で考慮すべき観点とテストの実行段階で考慮すべき観点があることが分かった。

これらの分析結果を踏まえ、仕様書記載外の問題を効果的に摘出するための観点を纏めることを考えた。
今回は、実際に発生した市場不具合の起因となった問題点から、当該問題を摘出するために必要だったテスト観点を教訓集として纏めた。

本発表では、以上の分析の流れや、得られた考察、そして作成した教訓集を実際の製品検査に適用した結果を報告する。

紹介文 :
　日本におけるソフトウェア開発の特徴として，異なる組織や企業に属するメンバで構成された混成チームによる開発がある．混成チームは多くの課題を抱えている．チームを形成し成長させるための支援の弱体化，組織や企業間の文化の違いによる異文化対立，業務請負に対応したコンプライアンスによるコミュニケーションの制約といった課題である．
　フェリカネットワークスでは，混成チームにおけるチーム力向上を目指し，メンバ間の仲間意識を高めるチームビルディングと共に，メンバによる問題解決をサポートする取り組みを行ってきた．メンバの意見や提案を聞き，問題解決を支援することを目的として，コンプライアンスを遵守したヒアリングの仕組みをつくった．この仕組みは，プロジェクトマネジャー，コーディネータ，メンバの 3 名で行う「三者ヒアリング」である．三者ヒアリングは，8 年間に渡って定期的に実施してきた．
　本論文では，三者ヒアリングの仕組みについて詳細に報告すると共に，ヒアリング記録を基に，ヒアリングの状態をグラフ表現で可視化し，分析する手法を提案する．また，この手法を用いてヒアリングの状態の分類を試みたので，その結果を報告する．

紹介文 :
本発表では、弊社移動機開発部における2013年以来の開発管理プロセスの改善活動について紹介する。
2013年当時、弊社スマートホン向けアプリケーション開発は早期リリース・マルチベンダ化が急速に進んだことで、プロセス整備が追い付かず、開発管理は部内各開発担当者・各ベンダに依存し統一性なく属人的なものとなっていた。また、リリース判定においても開発管理情報の相違から報告内容にバラツキがあり、第三者による品質判定の客観性・統一性向上も解決すべき大きな課題であった。
そこで、部内のプロセス改善チームにて、開発管理報告及びリリース判定時のソフトウェア品質報告の統一様式を作成し、全開発現場に導入した。また、開発現場に密着した人的支援、独自に構築したツールによる支援、現場の意見を取り入れた様式の継続的な改善等により、統一様式による客観的で定量的な指標を用いた開発管理が定着した。
これらの活動の結果、開発管理の精度が向上し、進捗遅延の減少・ソフトウェア品質の向上等の一定の成果を上げることが出来た。また、リリース判定様式の統一により、全プロジェクトを横並び・時系列で品質判定可能となり、客観的な品質判定プロセスを実現した。
本発表では、開発現場への改善施策定着に配慮したプロセス改善活動の内容や工夫した点について紹介する。

紹介文 :
企業のソフトウェア開発現場では、ある一定の品質管理基準を設けて達成すべき品質目標に向けて改善を行うことが一般的である。
しかしながら、基準達成を阻害するソフトウェア欠陥に対しては、何が欠陥であるか欠陥でないかの基準や回避方法が明確に示されないことも多く、品質の確保や改善を難しくしている現実がある。

本研究では、欠陥の定義を明確化するための特性として「基本特性」、また欠陥が混入してから獲得した性質を「混入特性」として整理した「欠陥特性」を提案する。
こうした欠陥が本来持つ性質を正確に定義し、それを踏まえた上での改善活動は、概念だけで語られるような議論を抑制し、現場の実態にあった適切な活動につながることが期待できる。

欠陥特性の有効性検証として、欠陥に対する認識共有の改善と、特性を利用した改善施策の評価を行った結果、提案する欠陥特性の有効性を確認した。本発表では、抽象的な概念である欠陥特性に対してなるべく具体的な事例と、従来の欠陥分類法とのアプローチの違いについて説明する。

紹介文 :
ソフトウェアの開発現場では，要求や仕様を伝える文書や，プロジェクトのメンバや外部に向けて業務の流れを説明する資料を用いている．要求や仕様，業務処理を文書で伝達する際に，認識のずれや記述不足があると，誤解や処理の抜けなど，コミュニケーションエラーによる手戻りが発生する．
本論文では，文章と図や表で構成された情報伝達型文書の曖昧さの問題に対して，書き手が主体的にコミュニケーションエラーになりうる箇所を検知するための「Ｗ検法」を提案する．
Ｗ検法は文書作成の最後，あるいは途中の段階で，厳密に仕様を記述するための形式仕様記述 VDM を組み合わせることで，文書の曖昧さを検知する手法である．
本論文では，実際の業務説明文書を題材として，Ｗ検法を行うことで形式仕様記述の初学者でも，書き手が自律的に曖昧さを検知できることを確認した．

紹介文 :
派生開発では新規開発時の作りの悪さや、その後の派生開発での変更作業によってソースコードの劣化が進んでいることが多く、変更ミスを引き起こす要因になっている。ソースコードの劣化を改善する方法としてリファクタリングがあるが、仕様の変更作業の中で、”良かれ“と思って、担当者の判断で安易に構造を変えてしまったり、無造作にリファクタリングにとりかかったりすることでかえって事態を悪化させることが多い。
XDDPでは、仕様変更の中でソースコードの劣化を和らげるために、当該関数に限定した「小さなリファクタリング」を許しているが、これだけでは足りない。
そこで、XDDPを応用してリファクタリングに特化した派生開発プロセスとして「R-XDDP」という方法を提案し、リファクタリング・パターンを限定しながら、混乱することなくリファクタリングに取り掛かる方法を勧めている。

紹介文 :
派生開発では機能の変更が中心であり、変更後のテストでも機能のデグレードに目が行きがちで、操作性や使い勝手が変化していることに気づくことは少なく、リリース後に「使いづらくなった」といったクレームが入ることがある。
また、操作に関連した変更の場合も、求められている操作性については確認するが、まったく意識していないところで影響がでることがある。
変更時に参照する機能仕様書や操作仕様書には、ユーザビリティについて詳しく書かれていないが、テストケースには、いろいろなケースが扱われている。
そこで、変更で影響を受けやすいユーザビリティの観点と関連するテストケースを組み合わせて「振る舞いbefore/afterシート」を作ることで、変更に伴うユーザビリティの影響に気づく方法を提供している。
この方法は、普段からテストケースを充実させておくことで対応しやすくなる。