SQuBok(R)分類検索
17 件の資料が見つかりました。
ダウンロード数: 3705回
年度 : 2007年   分科会 : 第5分科会「テスト」
紹介文 :
テスト終了判定基準について、その、客観性をどうやって確保したらよいかについて書いた論文です。 複数のメトリクスを取得し、多方面からの考察を加えることの重要さについて理解できます。 最終的に「金額」という統一メジャーで測定できないかという展望も述べられています。
ダウンロード数: 857回
紹介文 :
運用しているWebサイトの使用性(ユーザービリティ)を改善するために、簡易リモートUT(ユーザビリティテスト)を使った素早い課題抽出と、Webサイト目的・利用者ニーズに基づく優先順位づけを提案しています。 UXの専門知識を持たないWeb担当者でも実施可能なやり方になっています。
ダウンロード数: 810回
紹介文 :
フィールドで嫡出されたバグを分析して、嫡出漏れを防止するテストを特定する。また、そのテストケースを生成するテストケース設計技法を採用しているかを分析して、その組織に採用が必要なテスト技法を抽出する。 また、分析途中には、どの段階(テストレベル)でどのようなテスト技法を使えばどのようなバグを嫡出できるかという知識が必要になる。そのため、①テスト観点を仕様ベース、構造ベースで分類した表の作成、②テストレベルとテスト技法の関係、③その技法で嫡出可能なバグ例が報告されている。
ダウンロード数: 642回
紹介文 :
設計段階で数値要求又は数値定義を記述しないというバグを予防するため、仕様書に数値記入が必要と考えた振る舞いを定義した。それを使って仕様書の記述漏れ・誤りを抽出したことが報告されている。
ダウンロード数: 615回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。 そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。 この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。 逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。
ダウンロード数: 467回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人(熟練者)」に依存することが多いが、この研究では、共通仕様に関する変更情報を1箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。
ダウンロード数: 444回
年度 : 2012年   分科会 :
紹介文 :
2012年SQiP Effective Award受賞。 振り返りは、品質に貢献しないと思われています。そこで、「KPT」と「なぜなぜ分析」を組み合わせたKWS振り返りを作りました。 議論のフレームワーク、コミュニケーションのフレームワーク、振り返り結果の横展開のフレームワークで組織レベルの改善ができ、KWS振り返りでは、本音の議論ができ、真の原因も見つけられ、問題解決への意識が高まり、人材育成につながるなどの効果が見られます。
ダウンロード数: 403回
紹介文 :
プロセスを定着させる重要なポイントとして、継続的な改善がありますが、ここでは、継続的改善を具体的に行う手法/手順を提案しています。原因分析シート、不遵守原因リスト、対策分析シートを用いた方法は、具体的で説得力があり、ここで提案された方法を各所で実践されることをお薦めします。
ダウンロード数: 385回
年度 : 2012年   分科会 :
紹介文 :
市場での故障の低減を目指して、過去10年の故障を分析と問題点を明らかにしました。 それを整理して、テスト観点知識ベースの構築を行い、テスト設計に活用することで、テスト観点と項目の強化を行いました。 その分析から整理、解決策の検討からテスト設計への反映に対する取組みについて述べています。
ダウンロード数: 328回
SQuBOK分類 :
3.10.3.2  バグ分析
年度 : 2010年   分科会 : 第6分科会「派生開発」
紹介文 :
非熟練技術者プロジェクトではデグレードの防止が極めて難しいことに着目し、習熟度に関わらず変更内容に関するチェック項目を確認できる「気づきナビ」を提案しています。これにより、デグレード防止に必要な知識を補うことができるようになります。
ダウンロード数: 259回
紹介文 :
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか? 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。 この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。
ダウンロード数: 201回
年度 : 2012年   分科会 :
紹介文 :
CMMIと品質会計を軸にしながら、定量的管理プロセスを含む開発プロセスを構築したの事例です。 現状を分析しながら、一つずつ、一歩一歩 進めていくアプローチは、標準化に取り組むところ全てに参考になるものです。
ダウンロード数: 166回
紹介文 :
過去のレビュー指摘を分類・活用しようとすると、これまでは必ずと言っていいほど、管理者視点で行われてきた。 本論文では管理者視点と共存する形で、作成者視点の分類・活用方法が提案されている。 実験で付与されたタグは大きく6つに分類され、「機能系」「対応方法系」「品質特性系」だけでなく、「注意喚起系」「表現方法系」「影響度系」といった作成者ならでは視点があり、具体的なキーワードでタグが付与されている。 作成者にとってレビュー指摘を検索・活用しやすくなると共に、作成者自身が自由にタグを付与できるため、品質向上活動への能動的な関与の促進が期待できる。 レビュー指摘を組織的に蓄積・横展開し、作成時の品質向上に活用したいと考えている組織の方は、一読されることをお勧めする。
ダウンロード数: 129回
紹介文 :
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか? 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。 そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。
ダウンロード数: 126回
年度 : 2015年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では機能の変更が中心であり、変更後のテストでも機能のデグレードに目が行きがちで、操作性や使い勝手が変化していることに気づくことは少なく、リリース後に「使いづらくなった」といったクレームが入ることがある。 また、操作に関連した変更の場合も、求められている操作性については確認するが、まったく意識していないところで影響がでることがある。 変更時に参照する機能仕様書や操作仕様書には、ユーザビリティについて詳しく書かれていないが、テストケースには、いろいろなケースが扱われている。 そこで、変更で影響を受けやすいユーザビリティの観点と関連するテストケースを組み合わせて「振る舞いbefore/afterシート」を作ることで、変更に伴うユーザビリティの影響に気づく方法を提供している。 この方法は、普段からテストケースを充実させておくことで対応しやすくなる。
ダウンロード数: 97回
年度 : 2016年   分科会 : 第6分科会「派生開発」
紹介文 :
一般に、派生開発では機能の追加と変更が中心になる。その結果、応答時間などに変化が生じることがある。設計の担当者は応答時間の変化に気づかなかったり、気づいていた時でも、これくらいなら問題ないだろうと勝手に決め込んだりしていることが多く、納品後に「時間効率性」の劣化としてクレームとなる場合がある。時間効率性に関するクレームは、必ずしも遅くなったから問題になるとは限らない。派生開発の場合、使い慣れている状況に対して変化が許容範囲を超えると操作に影響を与えるからである。 設計者が応答時間等の劣化に気づかない理由として、ソースコードの該当箇所を探す際も、機能の変更に気を取られ、その機能が操作と絡んでいることに気がついていないことがある。そこで、変更要求を捉える段階で、メモリー処理や通信処理などの時間効率性に影響を与えそうな機能を変更するときには、時間の変化を予測して、「EMOT(Estimation Method Of Time behavior degradation)」の確認表を使って変化時間の目安を確認する。そこで事前に想定している許容範囲を超える時は、早めに依頼者と変更方法などを協議する。また他に変更方法がない時は、操作側で事前にトレーニングして備えてもらうことになる。こうした対応によって、後からのクレームになることを回避する。
ダウンロード数: 36回
紹介文 :
ファジーな機能を実現し、識別や予測の失敗発生は常に起きうるAIシステムに対しては、「納得して受け入れる」ことの困難さが言われています。 一方で、AIの出力等について説明を行うXAI(eXplainable AI)技術は大きな注目を浴びていますが、それが果たす役割についてはまだ合意がなされていません。 本研究では、特にAI専門家と非専門家の差に着目しつつ、納得という観点からAIの失敗やその説明に関する人間のとらえ方をしっかりと調査し論じています。
↑