キーワード検索


 2001年    2002年    2003年
 2004年    2005年    2006年
 2007年    2008年    2009年
 2010年    2011年    2012年
 2013年    2014年    2015年
 2016年    2017年    2018年
 2019年    2020年  
225 件の資料が見つかりました。
ダウンロード数: 2846回
紹介文 :
テスト観点の洗い出しにNGT(Notation for Generic Testing)を活用している。作成されたテスト観点テンプレートはドメインに依らず汎用性があるので、どのような組織にも参考になります。
ダウンロード数: 2708回
年度 : 2005年   分科会 : 第5分科会「テスト」
紹介文 :
ISO 9126などの品質特性を、実際の現場でどのように使えばいいのかの一方策が提案されています。通常は外部品質特性のみ着目されがちですが、内部品質特性も使用されており、開発する立場が考えねばならないことも組み込まれています。
使用する際は、プロジェクトごとに品質特性の捉え方は異なるので、チェック項目と特性のリンクを再考し、チェックリストの補足も、プロジェクトにあった形にすると、より使いやすいものになります。
ダウンロード数: 2657回
年度 : 2006年   分科会 : 第5分科会「テスト」
紹介文 :
テストの自動化に関心のあるプロジェクトは多いので、どのように導入を進めればいいのか、実際に導入するとどこで困るのかがわかりやすく書かれています。自動化の場合は特にそれに向けた戦略が重要なので、計画段階で自動化を見据えた計画にしても良いと思いますが、この報告に書かれているポイントを押さえる事で、自動化による「こんなはずではなかった」はかなり防げるのではないでしょうか。
ダウンロード数: 2483回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
開発期間が短い派生開発において、追加機能の要求仕様書が短期間に精度の高いものが書けることは重要だ。そこで仕様モレが少ない表記法として「USDM」を導入しようとしたが、従来の書き方に慣れた人たちにとってギャップが障壁となった。そこで慣れない現場の人たちを誘導するために何が必要かを「現場の目線」から探り出し、初心者向けにUSDMガイドラインを作成した。このような障壁は新しい方法を導入しようとするときにつきものであるが、その解決方法として今回のような優しく誘導するという取り組み方は、ガイドラインを作成することで推進者自身がその手法を理解することになり、いろんなケースに応用できる取り組み方である。
ダウンロード数: 2376回
紹介文 :
ソフトウェア成果物の品質を測定する際の、①プロセスに着目した評価方法と②プロダクトの品質特性に着目した評価方法の両面について整理し、開発現場で実践的に活用できる分析方法を提案しています。
ダウンロード数: 2369回
紹介文 :
改善推進側の立場から、『プロジェクト特性に見合ったレビュープロセスの適用』と『レビュー成熟度に応じたレビュー改善』を客観的な診断に基づき推進する手法を提案している。また、その診断を各プロジェクトが簡単に自己診断できるためのツールも開発しており、プロジェクトが自立的にレビュー改善を推進できるように工夫されている。
ダウンロード数: 2154回
紹介文 :
予め指摘難易度の異なる欠陥を埋め込んだ仕様書を被験者にレビューさせ、的確に指摘ができるかを見るという興味深い実験をしている。実験結果として、難易度が一番簡単な欠陥は有意に指摘率が高かった。指摘率と被験者の開発経験には有意な関係は見られなかった。実験結果は部分的な成果ではあったが、要求から仕様に落とす際のパターンをモデル化し、その難易度を設定した「要求分析スキルモデル」はスキル評価以外にも大いに活用できるであろう。
ダウンロード数: 2128回
紹介文 :
派生開発においては、全てのテストを実施する工数がないため、影響度分析を行い、関連する箇所を絞り込んでテストをすることが有効です。
本研究では、派生開発時の影響範囲を可視化し、機能間の関係性及び資源の共有について機能間マトリクスを作成するという方法を取っています。XDDPのTMと組み合わせることで派生開発時のテストの効率化が行えることでしょう。
ダウンロード数: 2076回
年度 : 2007年   分科会 : 第5分科会「テスト」
紹介文 :
前年度の直交表の報告の問題点に取り組んだ活動です。直交表を使う前段階で、何をテストすべきか、テストの漏れを防ぐにはどうしたらよいか、ということに着目したものになっており、テスト観点の抽出方法およびテスト技法の結びつけがわかりやすく書かれています。また、直交表に適さないテスト観点について検討されており、実践的です。
なお、ここではjennyを直交表のツールとして紹介していますので、直交表とAllPairを明確に区別したい場合は注意してください。
ダウンロード数: 1953回
紹介文 :
WEBシステムの状態遷移テストに特化した新しいテスト手法を考案した論文です。画面や、WEBならではのセッション管理、また、セキュリティ等々をどのようにモデル化し、テストケースにしていくか、実際に、ツールも開発し検証が行われています。
本論文は、5WCSQで報告されています。
ダウンロード数: 1915回
紹介文 :
要求仕様書の作成ページ数及び指摘件数とソース量とシステムテストでの障害件数等を採用し重回帰分析で上流での検出量からシステム試験での障害発生との相関を分析した研究論文。
ダウンロード数: 1840回
紹介文 :
ユーザーが陥ってしまう操作上での行き詰まりに対して、行為の7段階モデルを元に時系列をさかのぼって分析することで、より本質的な原因を探っています。
この方法を用いることで、ユーザーの心理や行動、認識まで意識することができるため、なぜなぜ分析単独では見つけにくい真因を見つけることができます。
ダウンロード数: 1776回
紹介文 :
プロジェクトの状況・内容・特性を把握し、そのプロジェクトにとってレビューの効果を最大限に発揮することを目的として、研究論文や書籍、SQiP研究会や各種勉強会、各研究員の現場での実践事例など、様々な所で語られているレビューにおける戦略の手法をレビューの計画・準備・実施・振り返りのプロセス毎に整理して「レビュー戦略マニュアル」にまとめている。レビュー戦略の立て方など具体的な事例が書かれており、実用性を考えた内容になっている。
ダウンロード数: 1765回
紹介文 :
UCD手法をアジャイル開発に取り入れて実施することで、ユーザビリティの高い製品を効果的に開発することができる方法を提案しています。短納期で使いやすいものを作ろうとする場合に参考になります。
ダウンロード数: 1761回
紹介文 :
各設計工程での手戻り削減と開発計画遵守を目的として、レビューを早期に実施する手法「TPR(TriPartition Review)」を提案している。
早期にレビューを実施するレビュー手法は過去にも提唱されているが、TPRは、各設計工程の期間を大枠・詳細・総合の3つのフェーズに分割し、各フェーズ終了時点の3回で、予め用意したレビュー観点表を用いてレビューを行うという手法で、レビューの実施時期とレビュー観点が決まっているので誰でも効果が得られるという点が特徴となっている。
ダウンロード数: 1622回
紹介文 :
品質確保の重要なポイントであるレビューをより効果的にするため、レビューによる指摘項目の、指摘分類、原因分類を最適化し、本質的な問題のみを対象とし、真の原因に応じた適切な対応が可能になるよう工夫をしています。レビューによる品質の評価を、単に指摘件数だけで評価するのではなく、指摘内容を踏まえてより正確にし、また、的確に品質向上につながる対応が取れるなど、有効な方法です。
ダウンロード数: 1622回
紹介文 :
リスク管理から閾値を超えた場合は課題管理にうつり、課題の振りかえりにより、次の開発時に新たなリスクの抽出にしよする。このリスクが閾値を超えた場合は課題管理にうつる。この無限につづく繰り返しを「乙∞(おつむげんだい)モデル」として開発した。課題管理プロセスとリスク管理プロセスを融合した、「乙∞(おつむげんだい)モデル」は、プロセス効果の定量化と合わせて有効性で現場で適用可能であると結論付けられた。
ダウンロード数: 1619回
SQuBOK分類 :
紹介文 :
発注者と協調した要求獲得、要求仕様記述において重要となる、コミュニケーション、その基盤、要求仕様定義と文書記述の方法についての課題を明らかにしたうえで、その具体的な解決手段について示しています。立場が異なる人びとが関わる要求獲得、「伝わるコミュニケーション」に悩んでいる人にとって、課題を解決していくための検討のきっかけの一つになるでしょう。
ダウンロード数: 1586回
年度 : 2009年   分科会 : 第6分科会「派生開発」
紹介文 :
XDDPは、派生開発に特化した開発プロセスであり、要求仕様からソースコードの変更までの範囲を扱う。一般に、プロセスは個人の習慣や組織の慣習になっているため、XDDPの導入の際にそれまでの慣習が障壁になる。本報告書は、「XDDPの導入障壁」を最初に扱ったもので、障壁の種類や背景について整理されており、さらにいくつかの障壁について克服のヒントを提示している。
ここから、XDDPに取り組む際にはどのような障壁が生じるか、またその克服方法を考えるヒントが得られるだろう。
ダウンロード数: 1581回
紹介文 :
仕様書のレビューをする際のレビューの観点を何にするかは,しばしば議論されている.本論文では,結論として,たとえそれを書いた設計者であっても,機能仕様書を作った後に思考をリセットしてテストエンジニアの視点(懐疑的な観点)を持ってレビューを行えば,効果的な結果を得られたことを示している.逆に,テストエンジニアが機能仕様書を書いても,設計者が書いたものと同様な欠陥を出していることを実験で示しているのが面白い.レビューの観点について考えさせられる論文である
             

1

2

3

4

5

6

7

8

9

10

11

12
↑