キーワード検索


 2001年    2002年    2003年
 2004年    2005年    2006年
 2007年    2008年    2009年
 2010年    2011年    2012年
 2013年    2014年    2015年
 2016年    2017年    2018年
 2019年  
25 件の資料が見つかりました。
ダウンロード数: 1358回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
我々の組織では、再発防止すべきと判断された不具合を特別なインシデント管理システムで管理し、再発防止策と共に記録している。
しかし、「どのようなテストを行えばその不具合を早期に発見できたのか?」については十分検討されているとは言えない状況であ
る。特に、システムテストなどの上位のテストレベルで発見すべき不具合であるほどその傾向が強いことが経験的にわかっている。た
だし、定量的には定かではない。そこで、現状の調査・分析を行うことにより不足しているテスト技術を特定し、それを補うための活
動を始めた。
まず、インシデント管理システムに記録されている不具合情報から、それらの不具合を発見するためにどのようなテスト分析/設計技
術が必要であったのかを分析した。次に、その分析結果を基に、幾つかの開発現場におけるシステムテストレベルのテスト分析/設計
プロセスを調査し、プロセス上の問題点を特定した。更に、それらの調査結果から判明した不足しているテスト技術を補うテスト分析
/設計手法を確立した。最後に、この手法をアンケートと実際の製品への適用により評価した。
提案手法の主な特徴は、テストタイプごとに思考過程を定めていること、不具合が起こりやすい条件「不具合誘発条件」を導出するこ
と、基本的なテスト設計技法の使用を促進することである。
本報告では、提案手法に至る一連の活動、提案手法およびその評価結果について述べる。
ダウンロード数: 1241回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
システム開発において品質目標値を見直す場合、適切な判断であれば、進行しているプロジェクトの改善にはとても有効である。問題はその適切な判断を行うために何を基準とするか?である。
今回はコード分析では定評のあるCKメトリクスを採用し、その判断基準に使用できるかを試みた。
CKは6種のメトリクスからなる、クラスに対する設計と複雑度を評価する尺度である。
採用した理由としては、設計成果であるコードの情報から判断基準を作成すれば、その時点での品質状況を推測でき、かつ開発途中の目標の変更を実施できるのではないかと考えたからである。
本発表では、実際の開発プロジェクトにこのCKメトリクスをどのように適用し、今回の目的である品質目標値を変更する基準作成がどの程度まで実施できたのか、この一連の取組みについて紹介する。
ダウンロード数: 836回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
アドバンテストではソフト開発の工期と品質を両立するため、トヨタ開発方式*1をカスタマイズ*2しソフト開発現場で利用している。

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

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

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

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

上記の活動を行った結果、パフォーマンスの向上成果を確認できたので紹介する。
ダウンロード数: 634回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
ソフトウェア開発工程における検出バグの真の根本原因追究とその根本原因に基づいた類似調査/再発防止策定までの一連の作業を標準化しているプロジェクトは多くはない。この一連の作業を標準化していないプロジェクトでは、同様なバグが類似調査で刈り取れずに流出し出荷品質の低下を招いたり、同様なバグを再発防止できずに以降の開発において再発させたりしている。
プロジェクトXにおいても同様でこの一連の作業を標準化しておらず、出荷後のバグ対応に追われていた。そのため、品質を改善すべく品質向上の取り組みとして各工程で検出されるバグの真の根本原因追究から根本原因に基づいた類似調査/再発防止策定までの作業を標準化し、更に開発プロセスを改善するためのPDCA改善サイクルも標準化し実施するように品質分析・評価プロセスを改善した。
その結果、①各工程におけるバグ混入が減少 ②類似調査により同様なバグが検出可能 ③再発防止によりフィードバック課題が明らかになった ④出荷後の発生バグが減少するといった効果を得られた。
本報告では、ソフトウェア開発における品質分析・評価プロセスの改善とその効果について事例紹介をする。同様の課題に悩んでいる開発者やプロジェクト管理者の方の参考となれば幸いである。
ダウンロード数: 540回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
近年では、システムテスト自動化を導入するプロジェクトも増加してきた。しかし、効果的に自動化されたテストを作成、運用するにはツールやライブラリを導入するだけでなく、テストプログラム自体の設計と作成、運用プロセスを改善する必要がある。正しく設計されていないテストプログラムでは以下の問題が発生する。

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

筆者は複数の企業、プロジェクトのテスト自動化支援をする中で、「操作技術」と「シナリオ」のモジュール分割に着目し、プログラム自身の品質向上と、作成、運用する上でのプロセスの改善を実践してきた。本発表では、それらの実践経験から設計のポイントと、分業方法、チーム間での連携を紹介する。
ダウンロード数: 247回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
CMMI(Capability Maturity Model Integration)を活用してプロセス改善に取り組む組織において、成熟度レベル達成と組織のビジネスゴール達成との関連についての関心は高い。組織的なプロセス改善に取り組み、CMMIの成熟度レベルが向上した場合には、それに伴って品質や生産性などの数値が向上することが期待される。実際に、CMMIに基づく改善の効果として、コスト面でのROI改善、見積り精度向上、失敗率の低減など、多くの事例が報告されている。しかしながら、結果としての品質や生産性の良否に影響を及ぼす要因について、開発中の品質や生産性に関するデータ(以降、プロセスデータと呼ぶ)に着眼して分析した研究事例は少ない。
本研究では、ソフトウェア品質の良否に影響を及ぼす要因についてプロセスデータを使用して分析を行った。また、成熟度レベル別に分析することにより、成熟度レベルによってソフトウェア品質の良否に影響を及ぼす要因がどのように変化するかについて考察した。
今回の分析により、成熟度レベルが上がるにつれて出荷後品質が向上することを確認した。また、ソフトウェア品質の良否に影響を及ぼす要因は、成熟度レベル毎に異なる結果となった。これらの分析結果を紹介し、効率的な品質改善に向け、各成熟度レベルで焦点を当てるべき改善のポイントについて述べる。
ダウンロード数: 208回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
近年の機能安全要求の高まりに伴い、車載開発では、顧客から要求を受けた場合、車載E&E機能安全規格ISO26262に基づき、三種類の確証方策(確証レビュー、機能安全監査、機能安全アセスメント)の実施を求められる。各確証方策の実施主体は、第三者性のみ規定され、部門は限定されていない。
三種類の確証方策を別々のイベントとして実施する場合、イベントが増えることで、開発プロジェクトの工数負担が多くなる。また、レビューアー・監査員・アセッサーという実施者を分ける場合、人員の確保、育成も必要になる。SQiP2012では、SQA監査をソフトウェアからシステムに拡張し、「機能安全監査」をSQA監査と同時に行う取組みを発表した。これに加えて、必要な確証方策を更に効率的に実施するために、これまで技術部門が担当していた「確証レビュー」を監査に融合させて実施することに取り組んだ。
本発表では、SQA監査・機能安全監査・確証レビューの融合の取組みについて共有する。
ダウンロード数: 190回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
GUI の試験において、テストケースや自動試験コードの作成・保守には多大な工数が掛かる。
本取り組みではそれらの作成を部分的に自動化することで、GUI自動試験の設計・実装の効率化を狙いとする。

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

本発表では開発中のアプリケーションに提案手法を適用した結果として、
・仕様分析に基づいて作成された試験項目数と自動生成されたテストケース数の比較
・自動試験コードの自動生成による開発コスト削減効果
という2点を主に述べる。
ダウンロード数: 163回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
 我々のプロジェクトでは組み込みソフトウェアの大規模化にともない、複数社のパートナーと協働して開発チームを構成している。製品を構成する機能部毎に開発チームを設け、相互に連携しながら開発と品質の作り込みを実施している。
 高い品質を確保するためには、開発チームが一丸となり、組織や会社間の枠を超えて改善活動を継続することが重要である。しかし、パートナーが異なる複数の開発チームの足並みを揃えて活動するためには、多くの壁を乗り越える必要があった。
例えば、活動評価の数値基準となる品質メトリクスにおいては、各パートナーの見識があり容易には統一できなかった。品質データの収集においては、パートナー工程におけるデータをプロジェクト全体で共有することへの抵抗もあった。また、社員とパートナーで一体となった改善活動、技術継承におけるパートナーとの人材育成計画の共有など、これら多様な課題に対して、アイデアを持ち寄り試行錯誤を繰り返しながら、全員で成果を共有することにより、弊社とパートナー間の高い相互信頼を築いてきた。
本発表では、15年にわたり継続してきた改善活動の中で苦労したこと、得られた成果について報告する。
ダウンロード数: 161回
SQuBOK分類 :
年度 : 2015年   分科会 : 2014年度第3分科会
紹介文 :
ソフトウェア開発において、有識者によるレビューは非常に重要である。しかし、ドメイン知識の豊富な有識者の数は限られており、有識者にかかる負担は大きい。有識者の負担を減らす為には、レビューアへの教育が必要である。我々はレビューアが早期にドメイン知識を習得し、より質の高いレビューができるようにするトレーニング手法について研究してきた。
我々は2014年度SQiP研究会にて仕様書に意図的にエラーを埋め込み、それをレビューする手法(EIDeR-Training 法:Error Injected Document Review -Training 法)を提案した。ドメインに特化した欠陥を仕様書に埋め込み、教材とすることで、失敗の疑似体験を可能とした方法である。EIDeR-Training 法の教材の作成は20分程度で可能であり有識者への負担は比較的少ない。実験から一定の効果は見られたものの効果にばらつきがあった。
本報告では効果にばらつきがみられる原因について考察し、EIDeR-Training法の改良を行った。実験の結果、シナリオレビューの手法を取り入れレビューアのレベルに合わせた教材を使ったEIDeR-Training法により、若手レビューアの不具合検出率は33%~300%向上した。
本報告では、提案手法とその実験の結果、考察について述べる。
ダウンロード数: 141回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
近年、自動車業界では安全性への関心が高まっており、機能安全規格ISO26262への準拠等、安全や品質保障への取り組みがますます重要となっている。一方、制御の高機能化によるソフトウェアの大規模化や、開発期間短縮への要求も強まっており、品質と効率の両立が大きな課題となっている。
弊社では、従来より、ISO26262相当のソフトウェアテストプロセスを構築している。主に、テストベンチを用いた結合テスト・システムテストの自動化に取り組んできたが、単体テスト(ホワイトボックステスト)においても自動化の可能性を検証すべく、Auto Test Generator(自動テスト生成ツール)の有効性・課題について評価した。今回は、その評価結果について報告する。
ダウンロード数: 136回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
大規模なソフトウェア開発プロジェクトの現場では、テストにより不具合が数千件摘出されることもある。従来は、不具合の発生傾向や改善が必要な箇所を把握するために、不具合情報へ「重要度」「現象分類」「原因分類」「作り込み工程」「摘出すべき工程」などの定型的な分類情報を付与し、それらの分類情報を機能やプログラムごとに集計することで品質状況の分析を行ってきた。
しかし、ソフトウェア開発プロジェクトで扱う問題は多岐にわたり、問題分析は、予め定義した分類種別を付与した不具合の分析だけではない。問題分析においては、分析する情報が定型的に分類されているとは限らず、また、分類されていたとしても、情報の欠落や属人的な分類判断により、しばしば精度に欠けた情報で分析を行わざるを得ないのが実状である。プロジェクトによって分析の目的/情報/期間はさまざまで、必ずしも上述の方法で品質状況や問題を的確に分析できるとは言えない。
そこで、複雑な情報を可視化する方法として「ネットワーク型データモデル」が研究されていることに着目し、不定形な情報をネットワーク図により可視化することで、分類種別に依存せず、問題点の発生傾向の把握および、改善が必要な箇所を分析できないか試みた。今回、その分析実施例と成果について発表する。
ダウンロード数: 110回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
本発表では、弊社移動機開発部における2013年以来の開発管理プロセスの改善活動について紹介する。
2013年当時、弊社スマートホン向けアプリケーション開発は早期リリース・マルチベンダ化が急速に進んだことで、プロセス整備が追い付かず、開発管理は部内各開発担当者・各ベンダに依存し統一性なく属人的なものとなっていた。また、リリース判定においても開発管理情報の相違から報告内容にバラツキがあり、第三者による品質判定の客観性・統一性向上も解決すべき大きな課題であった。
そこで、部内のプロセス改善チームにて、開発管理報告及びリリース判定時のソフトウェア品質報告の統一様式を作成し、全開発現場に導入した。また、開発現場に密着した人的支援、独自に構築したツールによる支援、現場の意見を取り入れた様式の継続的な改善等により、統一様式による客観的で定量的な指標を用いた開発管理が定着した。
これらの活動の結果、開発管理の精度が向上し、進捗遅延の減少・ソフトウェア品質の向上等の一定の成果を上げることが出来た。また、リリース判定様式の統一により、全プロジェクトを横並び・時系列で品質判定可能となり、客観的な品質判定プロセスを実現した。
本発表では、開発現場への改善施策定着に配慮したプロセス改善活動の内容や工夫した点について紹介する。
ダウンロード数: 107回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
ソフトウェアの欠陥が市場で顕在化した場合、その欠陥の修正にかかる費用やCS低下のリスクが大きい。このリスクを低減するために、開発中にできる限り欠陥を取り除いておく必要がある。
本論文は、出荷後の欠陥摘出の有無とプロダクトメトリクスとの関係に着目し、開発中の欠陥を取り除くプロセスとしてこれらの関係が活用できるか、日本電気株式会社と共同で実製品のデータを用いて分析を行った。
具体的には、ソースコードの有効行数と最大ネスティング数にしきい値を設定することで、しきい値以下としきい値を超えるグループで層別を行い、出荷後の欠陥摘出率に差異があるかの確認を行った。結果は、しきい値以下のグループよりもしきい値を超えるグループの出荷後の欠陥摘出率が高くなる傾向にあることが確認でき、プロダクトメトリクスがしきい値を超えるソースコードについては、開発プロセスにおいてより注意を払う必要があることを確認した。
上記を踏まえ、開発プロセスへの具体的な適用施策として、有効行数のしきい値を150行、最大ネスティング数のしきい値を4に設定すること、しきい値を超えるソースコードに対しては、しきい値以下のソースコードよりも注意深くレビューする、あるいはリファクタリング等を行うことを結論付けた。
本論文は、上記結論への導出過程を紹介する。
ダウンロード数: 104回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
ソフトウェアのテストは設計段階に作成した仕様書をベースに実施されるテストが多くの割合を占めているが、市場不具合の多くは仕様書記載外の問題に起因して発生している傾向が見えている。

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

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

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

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

本発表では、以上の分析の流れや、得られた考察、そして作成した教訓集を実際の製品検査に適用した結果を報告する。
ダウンロード数: 103回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
ソフトウェアの品質を測定するために,ソフトウェアテストを行うことが一般的だ.また,一般的にテストの品質を測定する方法として,テスト網羅率,つまりカバレッジを使用する.しかし,カバレッジが100%でもバグが検出されない例があるように,テストの品質をカバレッジのみで測定するのでは不十分な面がある.そこで注目されている手法として,「ミューテーション解析」と呼ばれる手法がある.
ミューテーション解析とは,テストのバグ検出能力を評価する手法で,ソフトウェアに意図的に加えた改変をテストが検出できるかどうかを検証する.加えた改変のうち,検出できた割合をミューテーションスコアと呼ぶ.ミューテーション解析を行うことで,これまで数値化できていなかったテストのバグ検出能力を数値化することが可能となる.これをうまく使うことでカバレッジだけでは不十分であったテストの評価能力の向上が見込まれている.
本発表では,ミューテーション解析の説明,実際に作成したミューテーション解析ツールをGitHubのプロジェクトに適用した結果,そして実用に向けての考察を行う.
ダウンロード数: 103回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
近年のソフトウェア開発は巨大化を続けており、それをサポートするように自動化ツールも普及してきている。そして、そのようなツールを使用してテスト自動化を行う組織も増えてきているが、当初期待していたような十分な効果が得られず取り組みを諦めるケースも発生している。
そのような状態に陥るのは、テスト自動化を行う際の注力すべきポイントが見つからないうえ、成功したとしても他者に事例を伝えるコストが高くつくからであろう。
そこで、このような問題を解決し、継続してテスト自動化の取り組みをサポートし続ける共通言語として「テスト自動化パターン言語」を紹介する。
ダウンロード数: 103回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
 日本におけるソフトウェア開発の特徴として,異なる組織や企業に属するメンバで構成された混成チームによる開発がある.混成チームは多くの課題を抱えている.チームを形成し成長させるための支援の弱体化,組織や企業間の文化の違いによる異文化対立,業務請負に対応したコンプライアンスによるコミュニケーションの制約といった課題である.
 フェリカネットワークスでは,混成チームにおけるチーム力向上を目指し,メンバ間の仲間意識を高めるチームビルディングと共に,メンバによる問題解決をサポートする取り組みを行ってきた.メンバの意見や提案を聞き,問題解決を支援することを目的として,コンプライアンスを遵守したヒアリングの仕組みをつくった.この仕組みは,プロジェクトマネジャー,コーディネータ,メンバの 3 名で行う「三者ヒアリング」である.三者ヒアリングは,8 年間に渡って定期的に実施してきた.
 本論文では,三者ヒアリングの仕組みについて詳細に報告すると共に,ヒアリング記録を基に,ヒアリングの状態をグラフ表現で可視化し,分析する手法を提案する.また,この手法を用いてヒアリングの状態の分類を試みたので,その結果を報告する.
ダウンロード数: 100回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
システム開発において、外部仕様書(要件定義書や外部設計書)の品質は、後続の成果物の品質やその作成に要する工数に多大な影響を与える。しかし、実際の開発では外部仕様書の作成やレビューに使える時間は限られており、外部仕様書のエラーを完全に除去することは現実的ではない。そこで、作成した外部仕様書が次工程の作業開始に問題ない品質を備えているかを系統的かつ簡便に評価する方法が求められる。本論文では、ファンクションポイント法(FP法)の計測観点にもとづき、外部仕様書の品質を定量的に評価する手法を提案する。提案方法では、“外部仕様が確定していればFPの値は一意に決まる”というFP法の原理を応用し、FPの値が一意に決められない記述は外部仕様が確定していないと判断する。またそれらをもとに、外部設計完了時点の外部仕様書に求められる情報量を100%の満点とした『外部仕様の確定度合い』を算出する。実際のプロジェクトに適用した結果では、外部仕様の確定度合いが高いプロジェクトほど、プロジェクトの実績が良いことがわかった。本手法を用いることで、外部仕様書の品質を系統的かつ簡便に評価でき、外部仕様が確定していない改善すべき箇所も明確にできる。
ダウンロード数: 91回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
派生開発の現場では,変更による影響範囲を特定できないことに起因する不具合が後を絶たない.
そこで,現場でどのように変更の影響範囲を特定しているのかをヒアリングしたところ,調査方法や調査結果の残し方が様々であることがわかった.
また,現場で行なわれている調査の仕方と派生開発に特化したアプローチであるXDDP(eXtreme Derivative Development Process)のプロセスを比較した.
その結果,多くの担当者が調査時に処理の順番に沿ってソースコードを読んでいることがわかった.
このコードリーディングの順番(ソースコードの探索ルート)では,調査範囲が狭くなり,本来目的別に分けて行なうべき調査を区別なく行なっているため,影響範囲の特定漏れを引き起こしやすくなるという課題が見えてきた.
この課題を解決するために,調査を事前調査,変更箇所調査,影響調査という3つのステージに分類し,ソースコードの探索ルートを内容に含む「標準調査プロセス」を定義した.
そして,「標準調査プロセス」を現場で有効に活用するために「調査プロセスガイドライン」を作成し,これらを用いて過去の事例をシミュレーションしたところ,変更の影響範囲の特定漏れを減少させることができた.
また,実プロジェクトに適用したところ,「標準調査プロセス」は技術的に難しいことはなく,現場で有効に活用できることがわかった.
  

1

2
↑