紹介文 :
システム開発において品質目標値を見直す場合、適切な判断であれば、進行しているプロジェクトの改善にはとても有効である。問題はその適切な判断を行うために何を基準とするか？である。
今回はコード分析では定評のあるCKメトリクスを採用し、その判断基準に使用できるかを試みた。
CKは6種のメトリクスからなる、クラスに対する設計と複雑度を評価する尺度である。
採用した理由としては、設計成果であるコードの情報から判断基準を作成すれば、その時点での品質状況を推測でき、かつ開発途中の目標の変更を実施できるのではないかと考えたからである。
本発表では、実際の開発プロジェクトにこのCKメトリクスをどのように適用し、今回の目的である品質目標値を変更する基準作成がどの程度まで実施できたのか、この一連の取組みについて紹介する。

紹介文 :
ソフトウェア開発工程における検出バグの真の根本原因追究とその根本原因に基づいた類似調査/再発防止策定までの一連の作業を標準化しているプロジェクトは多くはない。この一連の作業を標準化していないプロジェクトでは、同様なバグが類似調査で刈り取れずに流出し出荷品質の低下を招いたり、同様なバグを再発防止できずに以降の開発において再発させたりしている。
プロジェクトXにおいても同様でこの一連の作業を標準化しておらず、出荷後のバグ対応に追われていた。そのため、品質を改善すべく品質向上の取り組みとして各工程で検出されるバグの真の根本原因追究から根本原因に基づいた類似調査/再発防止策定までの作業を標準化し、更に開発プロセスを改善するためのPDCA改善サイクルも標準化し実施するように品質分析・評価プロセスを改善した。
その結果、①各工程におけるバグ混入が減少 ②類似調査により同様なバグが検出可能 ③再発防止によりフィードバック課題が明らかになった ④出荷後の発生バグが減少するといった効果を得られた。
本報告では、ソフトウェア開発における品質分析・評価プロセスの改善とその効果について事例紹介をする。同様の課題に悩んでいる開発者やプロジェクト管理者の方の参考となれば幸いである。

紹介文 :
我々の組織では、再発防止すべきと判断された不具合を特別なインシデント管理システムで管理し、再発防止策と共に記録している。
しかし、「どのようなテストを行えばその不具合を早期に発見できたのか？」については十分検討されているとは言えない状況であ
る。特に、システムテストなどの上位のテストレベルで発見すべき不具合であるほどその傾向が強いことが経験的にわかっている。た
だし、定量的には定かではない。そこで、現状の調査・分析を行うことにより不足しているテスト技術を特定し、それを補うための活
動を始めた。
まず、インシデント管理システムに記録されている不具合情報から、それらの不具合を発見するためにどのようなテスト分析/設計技
術が必要であったのかを分析した。次に、その分析結果を基に、幾つかの開発現場におけるシステムテストレベルのテスト分析/設計
プロセスを調査し、プロセス上の問題点を特定した。更に、それらの調査結果から判明した不足しているテスト技術を補うテスト分析
/設計手法を確立した。最後に、この手法をアンケートと実際の製品への適用により評価した。
提案手法の主な特徴は、テストタイプごとに思考過程を定めていること、不具合が起こりやすい条件「不具合誘発条件」を導出するこ
と、基本的なテスト設計技法の使用を促進することである。
本報告では、提案手法に至る一連の活動、提案手法およびその評価結果について述べる。

紹介文 :
アドバンテストではソフト開発の工期と品質を両立するため、トヨタ開発方式*1をカスタマイズ*2しソフト開発現場で利用している。

*1) 次の文献にて著者が名付けた開発方式であり、「欠陥」だけでなく開発工程で生じる「待ち」や「遅れ」の状態もムダとし、改善対象としている。
”トヨタ製品開発システム”James M.Morgan、Jeffrey K.Liker著

*2) カスタマイズし利用している内容は、次の４つの要素である。
・開発の流れの確立：マイルストーンによる同期化と平準化（SQiP2013にて発表）
・専門家チーム：継続改善を探究する技術者集団（SQiP2014にて発表）
・セットベース開発：多角的な視点から設計の最適解を導出（今回新たに発表）
・知識の再利用：必要な時に必要な知識を引き出す（今回新たに発表）

今回は、カスタマイズ内容を包括的に利用した結果を報告する。課題ばらしの質の確保や改善で使用した方法と指標を再利用することで、改善の継続性を確保する活動を行った。また、課題ばらしの結果を形式化し再利用することで、新規性が高い開発の際に、後から分かる課題を低減する活動を行った。この活動に際し、トヨタＡ３ストーリー*3を新たに導入した。

*3) Ａ３ストーリーとは、問題解決に関する内容を１枚の標準形式にまとめて伝達することを指す。

上記の活動を行った結果、パフォーマンスの向上成果を確認できたので紹介する。

紹介文 :
近年では、システムテスト自動化を導入するプロジェクトも増加してきた。しかし、効果的に自動化されたテストを作成、運用するにはツールやライブラリを導入するだけでなく、テストプログラム自体の設計と作成、運用プロセスを改善する必要がある。正しく設計されていないテストプログラムでは以下の問題が発生する。

・作成、メンテナンスが困難
・不安定ゆえの低速な実行速度
・分業が難しく、要員の確保が困難

筆者は複数の企業、プロジェクトのテスト自動化支援をする中で、「操作技術」と「シナリオ」のモジュール分割に着目し、プログラム自身の品質向上と、作成、運用する上でのプロセスの改善を実践してきた。本発表では、それらの実践経験から設計のポイントと、分業方法、チーム間での連携を紹介する。

紹介文 :
CMMI(Capability Maturity Model Integration)を活用してプロセス改善に取り組む組織において、成熟度レベル達成と組織のビジネスゴール達成との関連についての関心は高い。組織的なプロセス改善に取り組み、CMMIの成熟度レベルが向上した場合には、それに伴って品質や生産性などの数値が向上することが期待される。実際に、CMMIに基づく改善の効果として、コスト面でのROI改善、見積り精度向上、失敗率の低減など、多くの事例が報告されている。しかしながら、結果としての品質や生産性の良否に影響を及ぼす要因について、開発中の品質や生産性に関するデータ（以降、プロセスデータと呼ぶ）に着眼して分析した研究事例は少ない。
本研究では、ソフトウェア品質の良否に影響を及ぼす要因についてプロセスデータを使用して分析を行った。また、成熟度レベル別に分析することにより、成熟度レベルによってソフトウェア品質の良否に影響を及ぼす要因がどのように変化するかについて考察した。
今回の分析により、成熟度レベルが上がるにつれて出荷後品質が向上することを確認した。また、ソフトウェア品質の良否に影響を及ぼす要因は、成熟度レベル毎に異なる結果となった。これらの分析結果を紹介し、効率的な品質改善に向け、各成熟度レベルで焦点を当てるべき改善のポイントについて述べる。

紹介文 :
大規模なソフトウェア開発プロジェクトの現場では、テストにより不具合が数千件摘出されることもある。従来は、不具合の発生傾向や改善が必要な箇所を把握するために、不具合情報へ「重要度」「現象分類」「原因分類」「作り込み工程」「摘出すべき工程」などの定型的な分類情報を付与し、それらの分類情報を機能やプログラムごとに集計することで品質状況の分析を行ってきた。
しかし、ソフトウェア開発プロジェクトで扱う問題は多岐にわたり、問題分析は、予め定義した分類種別を付与した不具合の分析だけではない。問題分析においては、分析する情報が定型的に分類されているとは限らず、また、分類されていたとしても、情報の欠落や属人的な分類判断により、しばしば精度に欠けた情報で分析を行わざるを得ないのが実状である。プロジェクトによって分析の目的／情報／期間はさまざまで、必ずしも上述の方法で品質状況や問題を的確に分析できるとは言えない。
そこで、複雑な情報を可視化する方法として「ネットワーク型データモデル」が研究されていることに着目し、不定形な情報をネットワーク図により可視化することで、分類種別に依存せず、問題点の発生傾向の把握および、改善が必要な箇所を分析できないか試みた。今回、その分析実施例と成果について発表する。

紹介文 :
派生開発の現場では，変更による影響範囲を特定できないことに起因する不具合が後を絶たない．
そこで，現場でどのように変更の影響範囲を特定しているのかをヒアリングしたところ，調査方法や調査結果の残し方が様々であることがわかった．
また，現場で行なわれている調査の仕方と派生開発に特化したアプローチであるXDDP（eXtreme Derivative Development Process）のプロセスを比較した．
その結果，多くの担当者が調査時に処理の順番に沿ってソースコードを読んでいることがわかった．
このコードリーディングの順番(ソースコードの探索ルート)では，調査範囲が狭くなり，本来目的別に分けて行なうべき調査を区別なく行なっているため，影響範囲の特定漏れを引き起こしやすくなるという課題が見えてきた．
この課題を解決するために，調査を事前調査，変更箇所調査，影響調査という3つのステージに分類し，ソースコードの探索ルートを内容に含む「標準調査プロセス」を定義した．
そして，「標準調査プロセス」を現場で有効に活用するために「調査プロセスガイドライン」を作成し，これらを用いて過去の事例をシミュレーションしたところ，変更の影響範囲の特定漏れを減少させることができた．
また，実プロジェクトに適用したところ，「標準調査プロセス」は技術的に難しいことはなく，現場で有効に活用できることがわかった．

紹介文 :
ソフトウェア開発において、有識者によるレビューは非常に重要である。しかし、ドメイン知識の豊富な有識者の数は限られており、有識者にかかる負担は大きい。有識者の負担を減らす為には、レビューアへの教育が必要である。我々はレビューアが早期にドメイン知識を習得し、より質の高いレビューができるようにするトレーニング手法について研究してきた。
我々は2014年度SQiP研究会にて仕様書に意図的にエラーを埋め込み、それをレビューする手法（EIDeR-Training 法：Error Injected Document Review -Training 法）を提案した。ドメインに特化した欠陥を仕様書に埋め込み、教材とすることで、失敗の疑似体験を可能とした方法である。EIDeR-Training 法の教材の作成は20分程度で可能であり有識者への負担は比較的少ない。実験から一定の効果は見られたものの効果にばらつきがあった。
本報告では効果にばらつきがみられる原因について考察し、EIDeR-Training法の改良を行った。実験の結果、シナリオレビューの手法を取り入れレビューアのレベルに合わせた教材を使ったEIDeR-Training法により、若手レビューアの不具合検出率は３３％～３００％向上した。
本報告では、提案手法とその実験の結果、考察について述べる。

紹介文 :
近年の機能安全要求の高まりに伴い、車載開発では、顧客から要求を受けた場合、車載E&E機能安全規格ISO26262に基づき、三種類の確証方策（確証レビュー、機能安全監査、機能安全アセスメント）の実施を求められる。各確証方策の実施主体は、第三者性のみ規定され、部門は限定されていない。
三種類の確証方策を別々のイベントとして実施する場合、イベントが増えることで、開発プロジェクトの工数負担が多くなる。また、レビューアー・監査員・アセッサーという実施者を分ける場合、人員の確保、育成も必要になる。SQiP2012では、SQA監査をソフトウェアからシステムに拡張し、「機能安全監査」をSQA監査と同時に行う取組みを発表した。これに加えて、必要な確証方策を更に効率的に実施するために、これまで技術部門が担当していた「確証レビュー」を監査に融合させて実施することに取り組んだ。
本発表では、SQA監査・機能安全監査・確証レビューの融合の取組みについて共有する。

紹介文 :
　我々のプロジェクトでは組み込みソフトウェアの大規模化にともない、複数社のパートナーと協働して開発チームを構成している。製品を構成する機能部毎に開発チームを設け、相互に連携しながら開発と品質の作り込みを実施している。
　高い品質を確保するためには、開発チームが一丸となり、組織や会社間の枠を超えて改善活動を継続することが重要である。しかし、パートナーが異なる複数の開発チームの足並みを揃えて活動するためには、多くの壁を乗り越える必要があった。
例えば、活動評価の数値基準となる品質メトリクスにおいては、各パートナーの見識があり容易には統一できなかった。品質データの収集においては、パートナー工程におけるデータをプロジェクト全体で共有することへの抵抗もあった。また、社員とパートナーで一体となった改善活動、技術継承におけるパートナーとの人材育成計画の共有など、これら多様な課題に対して、アイデアを持ち寄り試行錯誤を繰り返しながら、全員で成果を共有することにより、弊社とパートナー間の高い相互信頼を築いてきた。
本発表では、15年にわたり継続してきた改善活動の中で苦労したこと、得られた成果について報告する。

紹介文 :
GUI の試験において、テストケースや自動試験コードの作成・保守には多大な工数が掛かる。
本取り組みではそれらの作成を部分的に自動化することで、GUI自動試験の設計・実装の効率化を狙いとする。

画面のテストケースには、操作対象のボタンや入力欄が異なるだけでほぼ同一の操作・確認を実施するものが多い。このことを利用して、以下の手法を提案する:
(1) 複数画面に適用可能なテスト内容を試験シナリオのパターンとして定義する。
(2) 上記パターンに対応した、自動試験コードの雛形を作成する。
(3) 画面上のオブジェクト名称をパラメータとして (2)の雛形に当てはめると、対応する自動試験コードが自動生成されるようにする。
この手法によってテストケースの設計と自動試験コードの実装が同時かつ効率的に実施可能になり、作業時間を削減できる。

本発表では開発中のアプリケーションに提案手法を適用した結果として、
・仕様分析に基づいて作成された試験項目数と自動生成されたテストケース数の比較
・自動試験コードの自動生成による開発コスト削減効果
という2点を主に述べる。

紹介文 :
近年、自動車業界では安全性への関心が高まっており、機能安全規格ISO26262への準拠等、安全や品質保障への取り組みがますます重要となっている。一方、制御の高機能化によるソフトウェアの大規模化や、開発期間短縮への要求も強まっており、品質と効率の両立が大きな課題となっている。
弊社では、従来より、ISO26262相当のソフトウェアテストプロセスを構築している。主に、テストベンチを用いた結合テスト・システムテストの自動化に取り組んできたが、単体テスト（ホワイトボックステスト）においても自動化の可能性を検証すべく、Auto Test Generator（自動テスト生成ツール）の有効性・課題について評価した。今回は、その評価結果について報告する。

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

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

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

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

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

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

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