キーワード検索


 2001年    2002年    2003年
 2004年    2005年    2006年
 2007年    2008年    2009年
 2010年    2011年    2012年
 2013年    2014年    2015年
 2016年    2017年    2018年
 2019年    2020年  
25 件の資料が見つかりました。
ダウンロード数: 307回
SQuBOK分類 :
年度 : 2016年   分科会 :
紹介文 :
一般にソフトウェア開発において欠陥の検出を上流化することは、下流であるテスト工程での品質を向上して手戻りを減らし、更には市場への流出低減にも効果があることが知られている。しかしその関係が定量的に示されることは稀であるため、具体的な目標設定に結びつかず、継続的な品質改善活動に繋がりにくい。実際、上流メトリクスを収集するのみで活用されていないケースや、メトリクスの収集自体していないケースはよく耳にするところである。
本研究ではレビューおよびテスト工程で検出される欠陥の数に対して、工程間で比をとった前倒し率という指標を用いて、上流のレビュー活動が下流のテスト工程に与える効果をモデル化し、定量評価できるようにする。次にこれを近似変換することで、上流工程終了時に下流工程での欠陥検出数を予測可能なモデルへと発展させる。
本発表では実際のプロジェクトデータを用いた検討の過程を段階的に示し、得られたモデル式とその精度の検証結果について報告する。
ダウンロード数: 306回
SQuBOK分類 :
年度 : 2016年   分科会 :
紹介文 :
派生開発の現場では、機能の追加・変更による振る舞いの変化が、思いもよらないユーザビリティの劣化を招くことがある。そのうえ、ユーザビリティに及ぼす影響への配慮不足により発生する不具合の多くが、開発の終盤やリリース後に発見され、納期遅延やコスト増大といった問題を引き起こしている。さらに、このような不具合は要求仕様書や変更設計書などドキュメントが揃っている現場でも発生する可能性がある。
そこで我々は、機能の追加・変更によって生じた振る舞いの変化を差分として明らかにし、振る舞いの差分からユーザビリティの劣化に気づくことで、設計段階でユーザビリティに関する不具合を防ぐ以下の三つの解決策を考案した。
・「派生開発で劣化し易いユーザビリティの観点」
・「振る舞いBefore/Afterシート」
・「ユーザビリティの劣化を防止するプロセス」
これらの解決策の効果を検証するため、過去の不具合事例や現在進行中のプロジェクトに適用したところ、機能の追加・変更による振る舞いの差分を設計担当者に意識させることができた。また、設計担当者が振る舞いの差分から、その変化がユーザビリティへ影響し劣化していないかを「派生開発で劣化し易いユーザビリティの観点」を用いて熟慮することで、ユーザビリティの劣化への気づきを得られることがわかった。
本報告では、これらの解決策を用いた派生開発でのユーザビリティの劣化を防ぐ方法について詳細を述べる。
ダウンロード数: 290回
SQuBOK分類 :
年度 : 2016年   分科会 :
紹介文 :
当社の品質保証部門ではJIS X 0129やJIS X 25051規格を参考にした品質評価プロセスが存在する。しかし、利用時の品質要求に対する方針は社内では規定されておらず、各プロジェクトに委ねられていた。当社ではPSQ認証取得を機に利用時の品質への取り組みを開始し、開発プロジェクト期間中に利用時の品質を測定する方法を検討した。
当社では各製品でペルソナを定義し、マニュアル毎の利用者を定義している。そこで、このマニュアル毎の利用者を活用し、過去にマニュアルを仕様書としてソフトウェアを動かしマニュアルの習得性および理解性の評価を行った実績がある。この実績をもとに品質保証部門でのペルソナを参考に利用者の分類を行い、この分類とマニュアルを仕様書として移用することで、開発プロジェクト期間での利用時の品質を評価するマニュアルベーステスト技法を構築した。JIS X 25051を参考に構築された品質保証プロセスを適用した複数の開発プロジェクトにマニュアルベーステスト技法を適用し、利用時の品質の評価を行った。
今回、このマニュアルベーステスト技法のプロセスの解説とともに、マニュアルベーステスト技法の評価結果および分析結果、今回の適用結果から得られた開発プロジェクト期間中での利用時の品質の評価可能な条件および今後の課題について報告を行う。
ダウンロード数: 258回
SQuBOK分類 :
年度 : 2016年   分科会 :
紹介文 :
当社のパソコン製品には、自社製アプリケーションだけでなく、約50本のISV(独立系ソフトウェアベンダー)製アプリケーションをプリインストールしている。ISVによるQAをパスしてから納品されたアプリケーションは、当社の受入部門による受入テスト、SI部門によるシステムテストを経て、QA部門による出荷監査を受け、重大な不具合がないことが保証され、出荷される。
筆者が所属する受入部門の任務は、受入テストの段階ですべての不具合を検出し、出荷監査では不具合が検出されないようにすることにある。しかし、実際には出荷監査で不具合が検出され、ISVへの緊急修正依頼、マニュアルへの注記、修正モジュールのWeb公開など、予定外の不具合対応に追われることが多い。受入テストでいかにして効率的に多くの不具合を検出できるかが課題である。
この課題に対し、“Exploratory Software Testing”という文献で提唱されている探索的テストを導入することで、受入テストにおける不具合検出効率向上を図った。同文献を参照しながら洗い出したテスト観点に基づく探索的テストを、従来のブラックボックステストと組み合わせることにより、テスト工数あたりの不具合検出数を向上させることができた。
本論文では、探索的テストを導入するにあたって実施した、探索的テストプロセスの定義、テストチームの編成、テスト観点の洗い出し、テスト工数の確保方法、および、実際の製品に適用した効果について報告する。
ダウンロード数: 232回
SQuBOK分類 :
年度 : 2016年   分科会 : 2017年度第7 分科会
紹介文 :
ソフトウェア開発の現場では、「障害票」の情報を共有して不具合の再発予防対策を立案する際に、対策が効かず同種の欠陥が混入されて、不具合を再発させてしまうことがある。
多くの欠陥は、混入要因として「個人に依存した要因」と「集団に起因した要因」に分類を行うことができる。しかしながら、不具合発生の瞬間を記載した「障害票」情報を基に分析を行うため、「障害票」に記載されない背景に潜む「集団に起因した要因」を把握することができず、「個人に依存した要因」に着目した再発予防対策を立案するため、対策として不十分であり、同種の不具合を再発させていると、我々は考えた。
本研究では、欠陥混入の背景となる「プロジェクトの体制や環境である周囲の状況」を「環境要因」と定義し、欠陥情報に「環境要因」の情報を付加して蓄積、情報共有することを提案して、その有効性を確認した。
この取り組みにより、欠陥が混入するメカニズムを理解することを促し、視点を拡げた有効な再発予防対策を立案できることが期待できる。組織として「欠陥情報」を価値あるものとするために必要なアプローチを提唱する。
   

1

2
↑