SQuBok(R)分類検索
129 件の資料が見つかりました。
ダウンロード数: 350回
紹介文 :
プロセスを定着させる重要なポイントとして、継続的な改善がありますが、ここでは、継続的改善を具体的に行う手法/手順を提案しています。原因分析シート、不遵守原因リスト、対策分析シートを用いた方法は、具体的で説得力があり、ここで提案された方法を各所で実践されることをお薦めします。
ダウンロード数: 349回
紹介文 :
1)要求の評価方法の研究 要求の具体的な検証方法として、「貢献度評価による、妥当性及び完全性の評価」を提案しています。 2)形式仕様記述言語による派生開発でのモデル検証 組み込みソフトウェアの派生開発において、スペックアウトした仕様を形式仕様記述言語を用いて整理した事例が紹介されています。 3)プロジェクト管理における統合モデルの提案 特性の異なるプロジェクトに対して統一的な概念で評価およびフィードバックを行うためのプロジェクト管理フレームワークを提案しています。
ダウンロード数: 346回
年度 : 2012年   分科会 :
紹介文 :
2012年SQiP Effective Award受賞。 振り返りは、品質に貢献しないと思われています。そこで、「KPT」と「なぜなぜ分析」を組み合わせたKWS振り返りを作りました。 議論のフレームワーク、コミュニケーションのフレームワーク、振り返り結果の横展開のフレームワークで組織レベルの改善ができ、KWS振り返りでは、本音の議論ができ、真の原因も見つけられ、問題解決への意識が高まり、人材育成につながるなどの効果が見られます。
ダウンロード数: 342回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。 そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。 この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。 逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。
ダウンロード数: 336回
紹介文 :
「開発の上流文書の質が良くないと下流のテストがタイヘンになる、だったらテストエンジニアが上流から関わってはどうか」というところから出発した報告です。テストエンジニアの視点は設計者や開発者とは異なることを利用し、テストで発見されるべきバグを要求仕様書の段階で見つける試みです。 設計・開発とテスト担当者が別のチームであるプロジェクトなどには、有効な考え方です。
ダウンロード数: 308回
年度 : 2012年   分科会 :
紹介文 :
市場での故障の低減を目指して、過去10年の故障を分析と問題点を明らかにしました。 それを整理して、テスト観点知識ベースの構築を行い、テスト設計に活用することで、テスト観点と項目の強化を行いました。 その分析から整理、解決策の検討からテスト設計への反映に対する取組みについて述べています。
ダウンロード数: 307回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人(熟練者)」に依存することが多いが、この研究では、共通仕様に関する変更情報を1箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。
ダウンロード数: 286回
年度 : 2004年   分科会 : 第7分科会「テスト」
紹介文 :
品質機能展開の二元表を用いて、コンポーネント(部品や関数)と要求および他のコンポーネントとの依存関係を識別しておくことで、要求の追加や変更等における影響範囲を容易に特定し、テスト範囲や優先順位の決定に役立てる方法を提案しています。提案方法の利用手順や典型的な利用方法が、例示を伴って具体的に示されており、利用の検討にあたり役立ちます。
ダウンロード数: 284回
紹介文 :
ペルソナやペーパプロトタイピングといった代表的なUser eXperience(UX)デザイン手法を組み合わせて具体的に用いた結果と、その結果から考察される効果や考慮点をまとめています。UXデザイン手法を学ぶ上でコンパクトに主要な手法がまとめられ、図解も多く役立ちます。
ダウンロード数: 282回
年度 : 2013年   分科会 :
紹介文 :
エンジン制御器(コントローラ)開発においてモデルベース開発(MBD)を導入することにより開発期間の短縮は実現できましたが開発プロセス後半の開発効率の低下は改善できなかったことからMBDの開発プロセスを見直しを行い、ソフトウェア構造と制御対象(プラント)に着目し、シミュレーションを用いるテスト駆動開発を取り入れたプロセス改善方法について提案しています。発表内容はエンジン制御に特化していますが、他の制御機器にも適用できる開発プロセスだと思います。
ダウンロード数: 280回
SQuBOK分類 :
3.10.3.2  バグ分析
年度 : 2010年   分科会 : 第6分科会「派生開発」
紹介文 :
非熟練技術者プロジェクトではデグレードの防止が極めて難しいことに着目し、習熟度に関わらず変更内容に関するチェック項目を確認できる「気づきナビ」を提案しています。これにより、デグレード防止に必要な知識を補うことができるようになります。
ダウンロード数: 278回
紹介文 :
ソフトウェアのテストについてはソフトウェア工学において研究が進んでいる分野ではあるが、そこにまた新たな視点が加わった。本論文はレビューで早期にエラーを検出する際に3つのレビュー観点を提案するものだ。レビュー品質の向上を目指す方にぜひご一読いただきたい。
ダウンロード数: 271回
紹介文 :
レビュー効率と効果向上に関する新技法の提案論文。欠陥検出率の向上と、コスト効果を改善する方法として、メトリクス測定+仮説立案を利用に言及している。 品質系、特にレビュー技法に対するメトリクス利用の論文は一般に少ないこと、また当該論文にて言及している「間接メトリクス」に関してはプロセスメトリクス・プロダクトメトリクスのいずれでもない新たなメトリクス分野として注目に値する。
ダウンロード数: 258回
年度 : 2013年   分科会 :
紹介文 :
レビューの適切な実施時期と適切な観点は悩ましい問題です。やり方によっては指摘内容が全く無駄になることも少なくありません。本発表はレビューの実施時期と観点を適切に変えましょう、といういわばあたりまえを地道にやっています。特にレビュー観点の4象限(粒度と誤り度合い)から導かれる、レビュー観点の実例が見所です。「誤り」軸で「誤りでない」ものは欠陥とは言えないのでは?という話はともかく、気軽に読めてすぐ実効に移せる実用性の高い内容になっています。
ダウンロード数: 250回
紹介文 :
効率的かつ効果的なテストを行うためには、テストアーキテクチャの設計が重要なポイントです。 そこで、発想を整理するマインドマップを使ってテスト観点を抽出し、その観点の整理方法とともに、テストプロセスを提案したのが、この論文です。 提案する手法は、実際にソフトウェアテスト技術振興協会(ASTER)の「テスト設計コンテスト」に出場して効果を検証したものです。
ダウンロード数: 246回
紹介文 :
エキスパートレビューアを育成するためのトレーニング手法として、特に伝え方や教育が難しいドメイン知識に着目し、経験の浅いプロジェクトメンバーに実務において失敗させずにドメイン知識を習得してもらう手法として、EIDeR-Training法(Error Injected Document Review - Training 法)を提案している。短時間での教材作成や、個人学習なのに疑似的失敗体験ができる仕掛けなど工夫がされている。
ダウンロード数: 242回
紹介文 :
シナリオテストは様々な組織で実践されていると思いますが、方法論は確立していないのが実状です。本論文のように具体的な手順とその実践例が示されているのは、非常に有益です。
ダウンロード数: 235回
紹介文 :
プログラムを自動解析・自動実行するConcolic Testingは、制御パスを通るテストケースを自動生成し、抽出した値を使ってパスを自動実行するテスト技術です。 この技術のツールであるCRESTを、リグレッションテストに適用し、利用方法と検証結果をまとめました。 Concolic Testingに取り組もうとする方や、リグレッションテストの自動化に興味のある方の一助となる論文です。
ダウンロード数: 226回
紹介文 :
研究対象を、プロジェクトの上流段階でのプロトタイプの作成 とペルソナ・シナリオに基づく検証(ウォークスルー)の二つに絞ったUCD(人間中心設計)手法の現場への適応研究。評価軸となるペルソナや、テストケースであるプロトタイプに求められる品質問題も垣間見えて興味深い。使い易さを設計/検証するには、どれだけの準備が必要なのかを疑似体験できる。尚、UCDは基本的にはUXD(ユーザ体験デザイン)と同義と思って頂いて差し支えない。
ダウンロード数: 219回
紹介文 :
ソフトウェア開発の現場で起きている失敗の原因とUX手法が解決できる問題を突き合わせることで、現場や問題の状況に合わせて適切なUX手法を選択することを提案している。単に手法ありきで導入するのではなく、本来の目的を把握・意識したうえで、本当に望まれている結果を導くための重要な考え方を提示している。
        

1

2

3

4

5

6

7
↑