SQuBok(R)分類検索
139 件の資料が見つかりました。
ダウンロード数: 833回
紹介文 :
現場の開発者がUX手法の本来の目的をしっかりと理解し、かつ手法の効果があがるように展開するためには、UX手法の有識者によるサジェストが有効であると提案している。UX手法の組織導入・展開を行う場合に有益な示唆を与えてくれる内容である。検証実験で使用したサンプルも付録に掲載されているので参考になる。
ダウンロード数: 817回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については,様々なアプローチが議論されています.このため,それぞれの特徴や役割分担を明確に踏まえ,問題に応じて選択し,組み合わせ活用することが重要です.本論文は,形式仕様記述手法と要求記述手法に関し,以前の位置づけ整理を踏まえ,具体的な手法確立に向けた試行を行っています.
ダウンロード数: 805回
SQuBOK分類 :
3.5.1  要求抽出
紹介文 :
研究会の研究員へのアンケート実施を通して、研究活動に対するニーズと満足度を把握する取り組みになっています。「満足度」をどのように評価すればよいか、考え方と手順が参考になります。
ダウンロード数: 804回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。 そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。 この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。 逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。
ダウンロード数: 796回
紹介文 :
レビューで重大な指摘をしても、修正されなければ意味がない。 本論文では、レビュー指摘を作成者に抵抗感なく伝えるための手法を提案している。 プロジェクトや作成者の状況などを配慮せず指摘を伝えてしまうと、作成者は抵抗感を抱き、指摘を素直に聞こうとはしない。 特に第三者レビューを実施している人は、悩まれているところだと思うので、一読頂きたい内容となっている。
ダウンロード数: 740回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発で常に悩まされる問題は、変更に伴って予想外のバグが発生することである。 そのための「気付き」の工夫は、これまでも「派生開発」の分科会でもテーマに取り上げられてきた。「DRBFM」の視点を取り入れて「品質」への支障を取り上げる研究も行われているが、それでは範囲が広がり過ぎて、この種の取り組みに慣れていない現場のエンジニアでは見逃しやすい。そこで研究員の組織の中で実際に起きている「影響」の問題を調べてみると、副作用が起きる「場」として「時間」や「メモリー領域」といった、いわゆる「リソース」に共通することに気付いた。「リソース」に着目する効果としては計測が可能で判断のための「限界値」が定義できることである。
ダウンロード数: 735回
紹介文 :
ソフトウェアテストの自動化ツールは、導入の要望は高いものの、効果や導入の準備などさまざまなことを考えるとなかなか踏み切れない方も 多いのではないでしょうか。 この論文は、テスト自動化への「取り組みやすさ」を考えて、段階的に導入を進める方法を提案しています。
ダウンロード数: 711回
紹介文 :
設計段階で数値要求又は数値定義を記述しないというバグを予防するため、仕様書に数値記入が必要と考えた振る舞いを定義した。それを使って仕様書の記述漏れ・誤りを抽出したことが報告されている。
ダウンロード数: 687回
年度 : 2010年   分科会 : 第6分科会「派生開発」
紹介文 :
通常、XDDPの変更プロセスでは「3点セット」を必須としている。これは派生開発で混乱している組織にあっては、この3点セットの成果物を作りながら作業を進めることで秩序を確保するのが狙い。しかしながら、ビジネス系においては「SLCP」などでそれなりの成果物が作られプロセスの秩序も維持されていることがある。また、短納期の要求などもあって、「3点セット」を作成することに抵抗がある。そのような中で、変更を含む要求仕様に関するトラブルに的を絞って取り組むことにしたケース。得意なケースなので、なぜこの「部分適用」の方法が可能なのか、本報告書から読み取って欲しい。
ダウンロード数: 687回
紹介文 :
トップレビューアの頭の中がのぞけたら・・・本論文の研修者たちは挑戦した。トップレビューアの思考プロセス、それがHDR法だ。もしこの方法で優秀なレビューアが育つなら試してみない手はない。悩みを抱えるPMや品質管理部門の方はぜひご一読をお勧めする。
ダウンロード数: 669回
紹介文 :
本研究は継続的にレビューする手法ContinuousReviwについて記すものである。レビュー品質の向上を目指すうえで、「短時間、レビューアのばらつき」の問題は大きい。CR法はプロセスを持つレビュー法であるが、参加者自身がレビューの目的とルールを定め、振り返りを行い、新たなレビュー観点やルールの変更を検討する。特にレビュー期間が限られているプロジェクトの品質担当者にご一読いただきたい。
ダウンロード数: 646回
紹介文 :
ソフトウェア開発において変更が発生したとき、すべての範囲をテストしなおすことは難しい場合に、回帰テストの優先順位をつける方法を提案しています。 限られた期間でデグレードの確認が必要な場合にお勧めです。
ダウンロード数: 646回
紹介文 :
本論文は、効率よく欠陥を検出できる上級テストエンジニアのテストスキルを、経験の浅い初級テストエンジニアに移転するためのテスト実施トレーニング手法を研究したものです。 具体的には、過去の欠陥情報から上級テストエンジニアのノウハウを抽出し、それをSOHT表にまとめてトレーニングすることで初級テストエンジニアのスキルを向上します。
ダウンロード数: 622回
紹介文 :
専門的なソフトウェアについて、利用者も気づいていない要求を抽出するために、該当ソフトウェアの初心者が熟練者に弟子入りして学ぶ様子を観察しています。 要求を実現する画面案と実機を組み合わせた簡易プロトタイプで評価することで、要求の妥当性検証を短期間・低コストで実施できるよう工夫されています。
ダウンロード数: 602回
紹介文 :
1)リスクを低減するプロジェクト計画についての一考察 要求分析工程のデザインレビューの評価結果から、成功/失敗を予測するモデル「プロジェクト失敗予測モデル」を提案しています。 2)『ソフトウェア開発プロセス点検』の実践と考察 点検の実施結果を定量的に可視化する指標「開発プロセス良好率」を提案しています。 3)4アイテム要求モデルによる要求分析 簡単に導入できる要求分析の手法として、4アイテム(現在の状態、望まれる状態、解決されるべき問題、要求)モデルによる分析方法を提案しています。
ダウンロード数: 585回
年度 : 2012年   分科会 :
紹介文 :
システム基盤の構築に要する工数見積もりに関する取組みは少ないものです。国内外の学術機構や企業における事例報告においても十分とは言えません。 そこで、非機能要求のコストに影響にする変数をコストドライバとして定義し定量化を試み、見積もりモデルの有意性を実績との比較で検証し評価しています。 そして、この見積もりモデルをWebツールとして社内展開し運用しています。
ダウンロード数: 578回
紹介文 :
1)要求の評価方法の研究 要求の具体的な検証方法として、「貢献度評価による、妥当性及び完全性の評価」を提案しています。 2)形式仕様記述言語による派生開発でのモデル検証 組み込みソフトウェアの派生開発において、スペックアウトした仕様を形式仕様記述言語を用いて整理した事例が紹介されています。 3)プロジェクト管理における統合モデルの提案 特性の異なるプロジェクトに対して統一的な概念で評価およびフィードバックを行うためのプロジェクト管理フレームワークを提案しています。
ダウンロード数: 549回
紹介文 :
仕様というソフトウェアの核となる成果物の品質向上について、「形式手法(形式仕様記述)」と「テスト」といった、視点や参加者が異なるコミュニティーにおいて、閉じた視点で別々に議論されてしまっていることが多くあります。本論文では、それらを一つの系統的な視点から比較、議論することを試みています。
ダウンロード数: 531回
年度 : 2013年   分科会 : 第6分科会「派生開発」
紹介文 :
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人(熟練者)」に依存することが多いが、この研究では、共通仕様に関する変更情報を1箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。
ダウンロード数: 517回
年度 : 2012年   分科会 :
紹介文 :
曖昧な表現によってソフトウェアに欠陥が作り込まれており、これらをレビューで見付けるにも限界がある。そこで社外の過去の研究成果をベースに曖昧な表現を機械的に検索できるチェックツールを開発し、レビュープロセスに組込んだ活動発表です。 レビュー前の仕様書に適用し、問題点が抽出出来ており、効果もあることが確認されています。
        

1

2

3

4

5

6

7
↑