SQuBok(R)分類検索
11 件の資料が見つかりました。
ダウンロード数: 1164回
年度 : 2014年   分科会 : 第6分科会「派生開発」
紹介文 :
データベース(以降、DB)を共有し合う業務システムでは、他システムのDBの変更が自システムへ与える影響を正確に把握し対処する必要がある。過去の不具合事例を分析したところ、データ項目間の関係性の変化やデータバランスの変化を発生させる類の変更は、不具合の可能性を見過ごしやすいことがわかった。そこで、DB変更時の必須チェック項目と、関連システムのTMを組み込んだシートを作成し、これを介して「変更要求」「理由(背景)」「想定される影響」を伝達するしくみを考案した。
ダウンロード数: 875回
年度 : 2014年   分科会 : 第6分科会「派生開発」
紹介文 :
既存システムに対して変更や機能追加を行う際、変更箇所や変更による影響範囲を特定するために既存システムのソースコードを調査する。この調査方法が人によって様々で、調査結果もレビューに耐えられるものではなかった。そこで、調査の目的を3種に分類し、標準調査プロセスと調査プロセスガイドラインを作成・検証した。
ダウンロード数: 549回
紹介文 :
ソフトウェア開発において変更が発生したとき、すべての範囲をテストしなおすことは難しい場合に、回帰テストの優先順位をつける方法を提案しています。 限られた期間でデグレードの確認が必要な場合にお勧めです。
ダウンロード数: 359回
紹介文 :
プロセスを定着させる重要なポイントとして、継続的な改善がありますが、ここでは、継続的改善を具体的に行う手法/手順を提案しています。原因分析シート、不遵守原因リスト、対策分析シートを用いた方法は、具体的で説得力があり、ここで提案された方法を各所で実践されることをお薦めします。
ダウンロード数: 322回
年度 : 2012年   分科会 :
紹介文 :
市場での故障の低減を目指して、過去10年の故障を分析と問題点を明らかにしました。 それを整理して、テスト観点知識ベースの構築を行い、テスト設計に活用することで、テスト観点と項目の強化を行いました。 その分析から整理、解決策の検討からテスト設計への反映に対する取組みについて述べています。
ダウンロード数: 293回
年度 : 2004年   分科会 : 第7分科会「テスト」
紹介文 :
品質機能展開の二元表を用いて、コンポーネント(部品や関数)と要求および他のコンポーネントとの依存関係を識別しておくことで、要求の追加や変更等における影響範囲を容易に特定し、テスト範囲や優先順位の決定に役立てる方法を提案しています。提案方法の利用手順や典型的な利用方法が、例示を伴って具体的に示されており、利用の検討にあたり役立ちます。
ダウンロード数: 243回
紹介文 :
プログラムを自動解析・自動実行するConcolic Testingは、制御パスを通るテストケースを自動生成し、抽出した値を使ってパスを自動実行するテスト技術です。 この技術のツールであるCRESTを、リグレッションテストに適用し、利用方法と検証結果をまとめました。 Concolic Testingに取り組もうとする方や、リグレッションテストの自動化に興味のある方の一助となる論文です。
ダウンロード数: 193回
年度 : 2013年   分科会 :
紹介文 :
インシデントレポート(バグレポート)は、今日のソフトウェア開発を行なっている多くの組織で利用されているが、何かしら問題を引き起こしている組織も多いのではないだろうか。本報告では、バグレポートが引き起こしている問題に関する調査をインターネットやイベントで行ない、現場ではどのような問題があるか報告している。また、アンケート結果から問題を回避するためのアンチパターンの一部を作成方針を報告している。
ダウンロード数: 16回
紹介文 :
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか? 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。 この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。
ダウンロード数: 14回
紹介文 :
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか? 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。 そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。
ダウンロード数: 5回
紹介文 :
AIブーム、特に自然言語処理技術の発展が騒がれる中、ソフトウェア開発においてもそれらの技術を活用したいという想いは、多くのソフトウェア技術者が持っているかと思います。 本研究では、障害票の関連性予測のタスクについて、最低限の準備により既存ツールを利用しても、一定の有効性が得られることを実証しました。 興味がある方々の第一歩のために有用な取り組みとなっています。
↑