SQuBok(R)分類検索
29 件の資料が見つかりました。
ダウンロード数: 188回
年度 : 2012年   分科会 :
紹介文 :
テストの実施状況を把握するのは何のためでしょうか。テストに関わる者の立場が違えば、必要とする情報も異なります。 本発表では、テスト管理者・テスト実施者・ソフトウェア開発者が、それぞれどんな情報が必要かを整理し、テスト管理上で有効な分析ビューを定義した事例をしています。
ダウンロード数: 140回
紹介文 :
過去のレビュー指摘を分類・活用しようとすると、これまでは必ずと言っていいほど、管理者視点で行われてきた。 本論文では管理者視点と共存する形で、作成者視点の分類・活用方法が提案されている。 実験で付与されたタグは大きく6つに分類され、「機能系」「対応方法系」「品質特性系」だけでなく、「注意喚起系」「表現方法系」「影響度系」といった作成者ならでは視点があり、具体的なキーワードでタグが付与されている。 作成者にとってレビュー指摘を検索・活用しやすくなると共に、作成者自身が自由にタグを付与できるため、品質向上活動への能動的な関与の促進が期待できる。 レビュー指摘を組織的に蓄積・横展開し、作成時の品質向上に活用したいと考えている組織の方は、一読されることをお勧めする。
ダウンロード数: 123回
紹介文 :
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか? 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。 この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。
ダウンロード数: 103回
年度 : 2015年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では機能の変更が中心であり、変更後のテストでも機能のデグレードに目が行きがちで、操作性や使い勝手が変化していることに気づくことは少なく、リリース後に「使いづらくなった」といったクレームが入ることがある。 また、操作に関連した変更の場合も、求められている操作性については確認するが、まったく意識していないところで影響がでることがある。 変更時に参照する機能仕様書や操作仕様書には、ユーザビリティについて詳しく書かれていないが、テストケースには、いろいろなケースが扱われている。 そこで、変更で影響を受けやすいユーザビリティの観点と関連するテストケースを組み合わせて「振る舞いbefore/afterシート」を作ることで、変更に伴うユーザビリティの影響に気づく方法を提供している。 この方法は、普段からテストケースを充実させておくことで対応しやすくなる。
ダウンロード数: 83回
年度 : 2016年   分科会 : 第6分科会「派生開発」
紹介文 :
一般に、派生開発では機能の追加と変更が中心になる。その結果、応答時間などに変化が生じることがある。設計の担当者は応答時間の変化に気づかなかったり、気づいていた時でも、これくらいなら問題ないだろうと勝手に決め込んだりしていることが多く、納品後に「時間効率性」の劣化としてクレームとなる場合がある。時間効率性に関するクレームは、必ずしも遅くなったから問題になるとは限らない。派生開発の場合、使い慣れている状況に対して変化が許容範囲を超えると操作に影響を与えるからである。 設計者が応答時間等の劣化に気づかない理由として、ソースコードの該当箇所を探す際も、機能の変更に気を取られ、その機能が操作と絡んでいることに気がついていないことがある。そこで、変更要求を捉える段階で、メモリー処理や通信処理などの時間効率性に影響を与えそうな機能を変更するときには、時間の変化を予測して、「EMOT(Estimation Method Of Time behavior degradation)」の確認表を使って変化時間の目安を確認する。そこで事前に想定している許容範囲を超える時は、早めに依頼者と変更方法などを協議する。また他に変更方法がない時は、操作側で事前にトレーニングして備えてもらうことになる。こうした対応によって、後からのクレームになることを回避する。
ダウンロード数: 61回
紹介文 :
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか? 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。 そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。
ダウンロード数: 32回
紹介文 :
開発中のプロセスメトリクス(レビューやテストの欠陥数や各工程の工数等)を使って、リリース後の不具合発生確率を予測するモデルをロジスティック回帰分析を用いて構築しています。一般的に予測モデルというと予測精度の高さにばかり焦点が当たりがちですが、本研究では予測精度よりもモデルの意味するところが、開発現場のプロセス改善に良い方向づけを与えるかどうかに拘ってモデル構築を行っています。また最初に構築したモデルは開発現場に提示しづらいものでしたが、説明変数の選択や使い方を工夫して、現場にとって納得感のあるモデルを構築することができました。メトリクスを活用して予測モデルを作成する際のエッセンスが詰まった研究となっていますので、是非とも参考にしてください。
ダウンロード数: 27回
紹介文 :
ソフトウェア及びシステムのテストでは、市場で発生する可能性のある故障発生数を予測して、テスト完了を判断方法や定量的な基準を明確にすることができていますか? これらは、特に自動車開発におけるテストで解決が難しい課題となっています。 この論文では、ソフトウェア開発委託取引先からの受入れテスト時に、市場発生する可能発生数の予測をして、テスト完了時期を判断する方法と基準について研究しています。このため、ソフトウェア信頼度成長モデルを用いた故障率の減衰予測と市場使用期間での累積故障発生数を指数関数モデル化した予測とを組み合わせた予測手法を提案・分析しています。さらに、ユースケーステスト結果も追加評価して潜在故障数を予測することによる二重判断、及び受入れテストでの検出故障が収束傾向にない場合の対策として、開発組織の原因分析・対策活動の促進状況の判断も加えて、故障の市場発生数を予想評価してテスト完了時期を判断する包括的な方法(「オーカマモデル」)を提案しています。
ダウンロード数: 23回
紹介文 :
ファジーな機能を実現し、識別や予測の失敗発生は常に起きうるAIシステムに対しては、「納得して受け入れる」ことの困難さが言われています。 一方で、AIの出力等について説明を行うXAI(eXplainable AI)技術は大きな注目を浴びていますが、それが果たす役割についてはまだ合意がなされていません。 本研究では、特にAI専門家と非専門家の差に着目しつつ、納得という観点からAIの失敗やその説明に関する人間のとらえ方をしっかりと調査し論じています。
   

1

2
↑