キーワード検索


 2001年    2002年    2003年
 2004年    2005年    2006年
 2007年    2008年    2009年
 2010年    2011年    2012年
 2013年    2014年    2015年
 2016年    2017年    2018年
 2019年    2020年  
34 件の資料が見つかりました。
ダウンロード数: 227回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
近年のソフトウェア開発は巨大化を続けており、それをサポートするように自動化ツールも普及してきている。そして、そのようなツールを使用してテスト自動化を行う組織も増えてきているが、当初期待していたような十分な効果が得られず取り組みを諦めるケースも発生している。
そのような状態に陥るのは、テスト自動化を行う際の注力すべきポイントが見つからないうえ、成功したとしても他者に事例を伝えるコストが高くつくからであろう。
そこで、このような問題を解決し、継続してテスト自動化の取り組みをサポートし続ける共通言語として「テスト自動化パターン言語」を紹介する。
ダウンロード数: 200回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
ソフトウェアの品質を測定するために,ソフトウェアテストを行うことが一般的だ.また,一般的にテストの品質を測定する方法として,テスト網羅率,つまりカバレッジを使用する.しかし,カバレッジが100%でもバグが検出されない例があるように,テストの品質をカバレッジのみで測定するのでは不十分な面がある.そこで注目されている手法として,「ミューテーション解析」と呼ばれる手法がある.
ミューテーション解析とは,テストのバグ検出能力を評価する手法で,ソフトウェアに意図的に加えた改変をテストが検出できるかどうかを検証する.加えた改変のうち,検出できた割合をミューテーションスコアと呼ぶ.ミューテーション解析を行うことで,これまで数値化できていなかったテストのバグ検出能力を数値化することが可能となる.これをうまく使うことでカバレッジだけでは不十分であったテストの評価能力の向上が見込まれている.
本発表では,ミューテーション解析の説明,実際に作成したミューテーション解析ツールをGitHubのプロジェクトに適用した結果,そして実用に向けての考察を行う.
ダウンロード数: 197回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
ソフトウェアのテストは設計段階に作成した仕様書をベースに実施されるテストが多くの割合を占めているが、市場不具合の多くは仕様書記載外の問題に起因して発生している傾向が見えている。

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

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

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

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

本発表では、以上の分析の流れや、得られた考察、そして作成した教訓集を実際の製品検査に適用した結果を報告する。
ダウンロード数: 196回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
テストケースの実行順序は、しばしば勘や経験に依存して決定されることがあるが、そのような場合にはブロッカーバグがテスト実行の後期に発見され、その
修正待ちによりテスト実行が遅延するといった問題が発生する可能性がある。こうした問題を経験に頼らず解決するには、自動的にテストケースの優先度付けを行うことで実行順序を最適化し、深刻なバグをより早期に発見できるようになることが望ましい。
また、ソフトウェアテストの外部委託市場は世界的にも拡大が予期されているが、そうした第三者テストにおいてテストはしばしばブラックボックスに実施さ
れる。しかしながら、ブラックボックステストにおいてテストケースの優先度付けを行う方法は、最適化に利用できる情報が限られていることもあり既存研究に
おいて充分に明らかではない。
そこで我々は、過去の類似プロダクトにおけるテスト実行結果を利用し、新規プロダクトにおいてブラックボックスに実施される単体・結合テストのテストケースを蟻コロニー最適化を用いて優先度付けする枠組みを提案する。なお、本件のアイディアはICST 2015において発表済みであるが、それに加え本稿では未
発表である、実験において手法を実プロダクトへ適用した際の工夫および結果の詳細について報告を行う。
ダウンロード数: 191回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
派生開発の現場では,変更による影響範囲を特定できないことに起因する不具合が後を絶たない.
そこで,現場でどのように変更の影響範囲を特定しているのかをヒアリングしたところ,調査方法や調査結果の残し方が様々であることがわかった.
また,現場で行なわれている調査の仕方と派生開発に特化したアプローチであるXDDP(eXtreme Derivative Development Process)のプロセスを比較した.
その結果,多くの担当者が調査時に処理の順番に沿ってソースコードを読んでいることがわかった.
このコードリーディングの順番(ソースコードの探索ルート)では,調査範囲が狭くなり,本来目的別に分けて行なうべき調査を区別なく行なっているため,影響範囲の特定漏れを引き起こしやすくなるという課題が見えてきた.
この課題を解決するために,調査を事前調査,変更箇所調査,影響調査という3つのステージに分類し,ソースコードの探索ルートを内容に含む「標準調査プロセス」を定義した.
そして,「標準調査プロセス」を現場で有効に活用するために「調査プロセスガイドライン」を作成し,これらを用いて過去の事例をシミュレーションしたところ,変更の影響範囲の特定漏れを減少させることができた.
また,実プロジェクトに適用したところ,「標準調査プロセス」は技術的に難しいことはなく,現場で有効に活用できることがわかった.
ダウンロード数: 187回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
システム開発において、外部仕様書(要件定義書や外部設計書)の品質は、後続の成果物の品質やその作成に要する工数に多大な影響を与える。しかし、実際の開発では外部仕様書の作成やレビューに使える時間は限られており、外部仕様書のエラーを完全に除去することは現実的ではない。そこで、作成した外部仕様書が次工程の作業開始に問題ない品質を備えているかを系統的かつ簡便に評価する方法が求められる。本論文では、ファンクションポイント法(FP法)の計測観点にもとづき、外部仕様書の品質を定量的に評価する手法を提案する。提案方法では、“外部仕様が確定していればFPの値は一意に決まる”というFP法の原理を応用し、FPの値が一意に決められない記述は外部仕様が確定していないと判断する。またそれらをもとに、外部設計完了時点の外部仕様書に求められる情報量を100%の満点とした『外部仕様の確定度合い』を算出する。実際のプロジェクトに適用した結果では、外部仕様の確定度合いが高いプロジェクトほど、プロジェクトの実績が良いことがわかった。本手法を用いることで、外部仕様書の品質を系統的かつ簡便に評価でき、外部仕様が確定していない改善すべき箇所も明確にできる。
ダウンロード数: 185回
SQuBOK分類 :
年度 : 2015年   分科会 : 2014年度第3分科会
紹介文 :
設計書が完成した時点でのみ実施するレビューでは,たとえレビューで適切な指摘ができたとしても,重大な欠陥が発見されると,その修正に大きな手戻りが発生する.また,残りの期間ではリカバリできない等の理由から,レビューによる是正効果が完全には発揮できていない問題がある.
その解決のために,我々は 3 分割レビューを提案する.3 分割レビューとは,各設計工程の期間を 3 分割し,1/3 時点,2/3 時点,3/3 時点の3回(以後「完成時点」と記載)で予め用意したレビュー観点表を用いてレビューを行うことで,手戻り工数削減,開発計画の遵守を実現させるためのレビュー手法である.
本提案の有効性を,基本設計工程の 1/3 時点レビューの実験より検証した.工程の 1/3時点であっても,設計の根幹に関わる重大欠陥の検出は可能であり,手戻り工数の削減,開発計画の遵守の 2 つの課題からも有効であるということを確認した.
また,プロジェクト特性に基づくレビュー観点表の具体例を複数作成し,現場適応性を高めた.
ダウンロード数: 184回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
 日本におけるソフトウェア開発の特徴として,異なる組織や企業に属するメンバで構成された混成チームによる開発がある.混成チームは多くの課題を抱えている.チームを形成し成長させるための支援の弱体化,組織や企業間の文化の違いによる異文化対立,業務請負に対応したコンプライアンスによるコミュニケーションの制約といった課題である.
 フェリカネットワークスでは,混成チームにおけるチーム力向上を目指し,メンバ間の仲間意識を高めるチームビルディングと共に,メンバによる問題解決をサポートする取り組みを行ってきた.メンバの意見や提案を聞き,問題解決を支援することを目的として,コンプライアンスを遵守したヒアリングの仕組みをつくった.この仕組みは,プロジェクトマネジャー,コーディネータ,メンバの 3 名で行う「三者ヒアリング」である.三者ヒアリングは,8 年間に渡って定期的に実施してきた.
 本論文では,三者ヒアリングの仕組みについて詳細に報告すると共に,ヒアリング記録を基に,ヒアリングの状態をグラフ表現で可視化し,分析する手法を提案する.また,この手法を用いてヒアリングの状態の分類を試みたので,その結果を報告する.
ダウンロード数: 181回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
本発表では、弊社移動機開発部における2013年以来の開発管理プロセスの改善活動について紹介する。
2013年当時、弊社スマートホン向けアプリケーション開発は早期リリース・マルチベンダ化が急速に進んだことで、プロセス整備が追い付かず、開発管理は部内各開発担当者・各ベンダに依存し統一性なく属人的なものとなっていた。また、リリース判定においても開発管理情報の相違から報告内容にバラツキがあり、第三者による品質判定の客観性・統一性向上も解決すべき大きな課題であった。
そこで、部内のプロセス改善チームにて、開発管理報告及びリリース判定時のソフトウェア品質報告の統一様式を作成し、全開発現場に導入した。また、開発現場に密着した人的支援、独自に構築したツールによる支援、現場の意見を取り入れた様式の継続的な改善等により、統一様式による客観的で定量的な指標を用いた開発管理が定着した。
これらの活動の結果、開発管理の精度が向上し、進捗遅延の減少・ソフトウェア品質の向上等の一定の成果を上げることが出来た。また、リリース判定様式の統一により、全プロジェクトを横並び・時系列で品質判定可能となり、客観的な品質判定プロセスを実現した。
本発表では、開発現場への改善施策定着に配慮したプロセス改善活動の内容や工夫した点について紹介する。
ダウンロード数: 173回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
ソフトウェア開発における欠陥の情報は,多くの組織で蓄積されている.
混入し得る欠陥を予測し,欠陥の混入・流出を防止するためには,この蓄積された欠陥情報を活用することが不可欠である.
本研究では,欠陥の混入を予測するためには,欠陥が混入するメカニズムを理解し,欠陥を引き起こす要因を検知する必要があるということに着目し,その方法を検討した.
本発表では,欠陥の予測を目的とした,欠陥混入メカニズムのモデリング手法と欠陥データベースの構築・利用手法を提案する.
ダウンロード数: 144回
年度 : 2015年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では新規開発時の作りの悪さや、その後の派生開発での変更作業によってソースコードの劣化が進んでいることが多く、変更ミスを引き起こす要因になっている。ソースコードの劣化を改善する方法としてリファクタリングがあるが、仕様の変更作業の中で、”良かれ“と思って、担当者の判断で安易に構造を変えてしまったり、無造作にリファクタリングにとりかかったりすることでかえって事態を悪化させることが多い。
XDDPでは、仕様変更の中でソースコードの劣化を和らげるために、当該関数に限定した「小さなリファクタリング」を許しているが、これだけでは足りない。
そこで、XDDPを応用してリファクタリングに特化した派生開発プロセスとして「R-XDDP」という方法を提案し、リファクタリング・パターンを限定しながら、混乱することなくリファクタリングに取り掛かる方法を勧めている。
ダウンロード数: 142回
SQuBOK分類 :
年度 : 2015年   分科会 : 2014年度第7分科会
紹介文 :
企業のソフトウェア開発現場では、ある一定の品質管理基準を設けて達成すべき品質目標に向けて改善を行うことが一般的である。
しかしながら、基準達成を阻害するソフトウェア欠陥に対しては、何が欠陥であるか欠陥でないかの基準や回避方法が明確に示されないことも多く、品質の確保や改善を難しくしている現実がある。

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

欠陥特性の有効性検証として、欠陥に対する認識共有の改善と、特性を利用した改善施策の評価を行った結果、提案する欠陥特性の有効性を確認した。本発表では、抽象的な概念である欠陥特性に対してなるべく具体的な事例と、従来の欠陥分類法とのアプローチの違いについて説明する。
ダウンロード数: 140回
SQuBOK分類 :
年度 : 2015年   分科会 :
紹介文 :
ソフトウェアの開発現場では,要求や仕様を伝える文書や,プロジェクトのメンバや外部に向けて業務の流れを説明する資料を用いている.要求や仕様,業務処理を文書で伝達する際に,認識のずれや記述不足があると,誤解や処理の抜けなど,コミュニケーションエラーによる手戻りが発生する.
本論文では,文章と図や表で構成された情報伝達型文書の曖昧さの問題に対して,書き手が主体的にコミュニケーションエラーになりうる箇所を検知するための「W検法」を提案する.
W検法は文書作成の最後,あるいは途中の段階で,厳密に仕様を記述するための形式仕様記述 VDM を組み合わせることで,文書の曖昧さを検知する手法である.
本論文では,実際の業務説明文書を題材として,W検法を行うことで形式仕様記述の初学者でも,書き手が自律的に曖昧さを検知できることを確認した.
ダウンロード数: 104回
年度 : 2015年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では機能の変更が中心であり、変更後のテストでも機能のデグレードに目が行きがちで、操作性や使い勝手が変化していることに気づくことは少なく、リリース後に「使いづらくなった」といったクレームが入ることがある。
また、操作に関連した変更の場合も、求められている操作性については確認するが、まったく意識していないところで影響がでることがある。
変更時に参照する機能仕様書や操作仕様書には、ユーザビリティについて詳しく書かれていないが、テストケースには、いろいろなケースが扱われている。
そこで、変更で影響を受けやすいユーザビリティの観点と関連するテストケースを組み合わせて「振る舞いbefore/afterシート」を作ることで、変更に伴うユーザビリティの影響に気づく方法を提供している。
この方法は、普段からテストケースを充実させておくことで対応しやすくなる。
   

1

2
↑