SQuBok(R)分類検索
39 件の資料が見つかりました。
ダウンロード数: 2625回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については、様々なアプローチが議論されています。このため、それぞれの特徴や役割分担を明確に踏まえ、問題に応じて選択し、組み合わせ活用することが重要です。本論文は、形式仕様記述手法と要求記述手法に関し、この観点から位置づけの整理を試みています。
ダウンロード数: 1573回
紹介文 :
Blogなどの不特定多数の人が利用するサービスにおいては、誰がどんな目的で利用するのか把握することは難しいですが、コミュニケーション(多い・少ない)と読み手(特定・不特定)の2軸により整理することでうまく整理しています。ターゲットユーザーを想定する際の試行錯誤の過程も提示してあるので、ペルソナ法をどのように適用すべきか、1つの事例として参考になります。
ダウンロード数: 1393回
紹介文 :
今日、単に機能面の品質が良いというだけでは買ってもらえない。コスト(価格)や「プラスα」の何かが必要。そこでサービス品質を、この「プラスα」のひとつとして捉える。しかしなから、サービス品質は一様ではないため、お客様の要求を掴むためのプロセスの明確化とサービス要求の定量化が必要になる。 本報告書では、サービス品質をお客様の満足度で捉えている。このお客様満足度を掴むプロセスの一つとして「アンケート調査」があるが、これは集計までの時間がかかることと、そこから具体的なアクションを引き出しにくいという欠点がある。そ
ダウンロード数: 1226回
紹介文 :
予め指摘難易度の異なる欠陥を埋め込んだ仕様書を被験者にレビューさせ、的確に指摘ができるかを見るという興味深い実験をしている。実験結果として、難易度が一番簡単な欠陥は有意に指摘率が高かった。指摘率と被験者の開発経験には有意な関係は見られなかった。実験結果は部分的な成果ではあったが、要求から仕様に落とす際のパターンをモデル化し、その難易度を設定した「要求分析スキルモデル」はスキル評価以外にも大いに活用できるであろう。
ダウンロード数: 1007回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
開発期間が短い派生開発において、追加機能の要求仕様書が短期間に精度の高いものが書けることは重要だ。そこで仕様モレが少ない表記法として「USDM」を導入しようとしたが、従来の書き方に慣れた人たちにとってギャップが障壁となった。そこで慣れない現場の人たちを誘導するために何が必要かを「現場の目線」から探り出し、初心者向けにUSDMガイドラインを作成した。このような障壁は新しい方法を導入しようとするときにつきものであるが、その解決方法として今回のような優しく誘導するという取り組み方は、ガイドラインを作成することで推進者自身がその手法を理解することになり、いろんなケースに応用できる取り組み方である。
ダウンロード数: 802回
紹介文 :
要求仕様書の品質を上げるための施策を3つ提案している.一つはWモデルの考えで,要求仕様書とテスト設計書を同時作成し,テスト設計書から要求仕様書にフィードバックをかけるとうもの.もう一つは,仕様書にハイパーテキストを使って,仕様書間の矛盾を発見しやすくしたもの.最後は,記載漏れを防ぐためのチェックリストを提案している.
ダウンロード数: 578回
紹介文 :
プロトタイプを用いることでお客様の真の要求を掴み、サービス品質を高めることで、CS(Customer Satisfaction)を超えるCD(Customer Delight):顧客歓喜を実現するプロセスが提案されています。業績向上、従業員満足度向上につながるサイクルも提示され、経営者にとっても魅力的な研究内容になっています。
ダウンロード数: 520回
紹介文 :
2001年時点での「創造的なシステム開発」の方法(=情報システムにおける要求分析の方法)について述べている。論点は、情報システム発注者の「欲しいもの」だけでなく、発注者の先にいる利用者の「欲しいはずのもの」までを捕えるというところにある。この考え方は、2013年時点では当たり前になっているが、実現の度合いから言うと難しい問題として残っている。
ダウンロード数: 512回
紹介文 :
「一般的な言語 対 ドメイン特化言語」、「上流での実装詳細の捨象の程度」など、記述方式の特化性はソフトウェア開発における難しい問題です。本論文は、フレームワークを用いた開発における形式仕様記述の活用に関し、この問題について様々な観点からの試行と議論を試みています。
ダウンロード数: 511回
年度 : 2004年   分科会 : 第7分科会「テスト」
紹介文 :
機能追加時に追加機能と既存機能との組み合わせテストを実施するにあたり、重要な組み合わせを絞り込むために、類語辞典(シソーラス)を用いて、追加機能の説明文に含まれるキーワードの類似語や反対語を含む既存機能を関連機能として抽出する手法を提案しています。手軽に実施できる可能性がある点がよく、また着眼点として、テストケースの絞り込みにあたり役立てられる可能性があります。
ダウンロード数: 484回
紹介文 :
サービス品質(含:顧客満足(CS)、および従業員満足(ES))に関する研究論文。特にCSとCD(Customer Delight)について考察し、さらにはCDに関するプロセスについて言及している点がテーマとして特筆に値する。主たる顧客満足において「感動」の重要性を考察している。 特にマーケティングの父:フィリップ・コトラーの顧客満足度の4段階、およびカール・アルブレヒトのホッケースティック・ロイヤリティを引用しながらサービス品質に必要な「感動」を解説している点がユニークである。
ダウンロード数: 328回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については,様々なアプローチが議論されています.このため,それぞれの特徴や役割分担を明確に踏まえ,問題に応じて選択し,組み合わせ活用することが重要です.本論文は,形式仕様記述手法と要求記述手法に関し,以前の位置づけ整理を踏まえ,具体的な手法確立に向けた試行を行っています.
ダウンロード数: 287回
SQuBOK分類 :
3.5.1  要求抽出
紹介文 :
研究会の研究員へのアンケート実施を通して、研究活動に対するニーズと満足度を把握する取り組みになっています。「満足度」をどのように評価すればよいか、考え方と手順が参考になります。
ダウンロード数: 283回
紹介文 :
1)リスクを低減するプロジェクト計画についての一考察 要求分析工程のデザインレビューの評価結果から、成功/失敗を予測するモデル「プロジェクト失敗予測モデル」を提案しています。 2)『ソフトウェア開発プロセス点検』の実践と考察 点検の実施結果を定量的に可視化する指標「開発プロセス良好率」を提案しています。 3)4アイテム要求モデルによる要求分析 簡単に導入できる要求分析の手法として、4アイテム(現在の状態、望まれる状態、解決されるべき問題、要求)モデルによる分析方法を提案しています。
ダウンロード数: 253回
紹介文 :
現場の開発者がUX手法の本来の目的をしっかりと理解し、かつ手法の効果があがるように展開するためには、UX手法の有識者によるサジェストが有効であると提案している。UX手法の組織導入・展開を行う場合に有益な示唆を与えてくれる内容である。検証実験で使用したサンプルも付録に掲載されているので参考になる。
ダウンロード数: 240回
年度 : 2004年   分科会 : 第7分科会「テスト」
紹介文 :
品質機能展開の二元表を用いて、コンポーネント(部品や関数)と要求および他のコンポーネントとの依存関係を識別しておくことで、要求の追加や変更等における影響範囲を容易に特定し、テスト範囲や優先順位の決定に役立てる方法を提案しています。提案方法の利用手順や典型的な利用方法が、例示を伴って具体的に示されており、利用の検討にあたり役立ちます。
ダウンロード数: 232回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上について、「形式手法(形式仕様記述)」と「テスト」といった、視点や参加者が異なるコミュニティーにおいて、閉じた視点で別々に議論されてしまっていることが多くあります。本論文では、それらを一つの系統的な視点から比較、議論することを試みています。
ダウンロード数: 219回
紹介文 :
ペルソナやペーパプロトタイピングといった代表的なUser eXperience(UX)デザイン手法を組み合わせて具体的に用いた結果と、その結果から考察される効果や考慮点をまとめています。UXデザイン手法を学ぶ上でコンパクトに主要な手法がまとめられ、図解も多く役立ちます。
ダウンロード数: 185回
紹介文 :
1)要求の評価方法の研究 要求の具体的な検証方法として、「貢献度評価による、妥当性及び完全性の評価」を提案しています。 2)形式仕様記述言語による派生開発でのモデル検証 組み込みソフトウェアの派生開発において、スペックアウトした仕様を形式仕様記述言語を用いて整理した事例が紹介されています。 3)プロジェクト管理における統合モデルの提案 特性の異なるプロジェクトに対して統一的な概念で評価およびフィードバックを行うためのプロジェクト管理フレームワークを提案しています。
ダウンロード数: 176回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。 そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。 この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。 逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。
  

1

2
↑