SQuBok(R)分類検索
16 件の資料が見つかりました。
ダウンロード数: 21859回
紹介文 :
情報資産のリスク分析にあたり、各資産の機密性、完全性、可用性を評価する際の判定基準や観点をチェックリストととしてまとめており、同種のリスク分析の実行や方法を検討する際に参考となります。外部で公開されている「情報セキュリティポリシー・サンプル」の要点をまとめた付録も参考になります。
ダウンロード数: 5600回
紹介文 :
一つの典型例としての企業モデルを作成し、それに対するリスク分析やセキュリティ対策の検討結果を報告しています。同種の調査研究を進めるうえで、分析・対策手法を比較検討する際の共通課題として役立てられる可能性があります。
ダウンロード数: 1550回
紹介文 :
Blogなどの不特定多数の人が利用するサービスにおいては、誰がどんな目的で利用するのか把握することは難しいですが、コミュニケーション(多い・少ない)と読み手(特定・不特定)の2軸により整理することでうまく整理しています。ターゲットユーザーを想定する際の試行錯誤の過程も提示してあるので、ペルソナ法をどのように適用すべきか、1つの事例として参考になります。
ダウンロード数: 1111回
紹介文 :
UCD手法をアジャイル開発に取り入れて実施することで、ユーザビリティの高い製品を効果的に開発することができる方法を提案しています。短納期で使いやすいものを作ろうとする場合に参考になります。
ダウンロード数: 679回
紹介文 :
ウェブ・ユーザビリティが着目・重要視され始めた当時(2001年)に、ユーザビリティテストを自ら実施することで知見を獲得するとともに、ECサイトのランキングとユーザビリティの高さの相関関係を探っています。ユーザビリティの定量化により品質管理の枠組みに取り入れるようとする際に、考え方として参考になる文献です。
ダウンロード数: 266回
紹介文 :
・パッチの情報を追いかけ適用について。特にパッチ起因の障害発生の可能性とパッチ検証の工数猶予がない問題を解説。NISTの文献 SP800-40(Procedures for Handling Security Patches:米国国家の連邦組織利用のパッチ適用標準)を中心に研究した成果が記載されている。 ・また当該NIST基準について国内で展開した場合での弊害/課題についても深く考察されており、2005年当時の課題が今でも有効である点は特筆に値する。(例:NIST標準の適用事業規模、パッチ検証環境の保持困難、管理者負荷、言語の壁他) ・情報セキュリティ早期警戒体制の拡充、強化の一環として、平成16年7月7日に経済産業省から発表された「ソフトウェア等脆弱性関連情報取り扱い基準」および「情報セキュリティ早期警戒パートナーシップガイドライン」についても解説している。
ダウンロード数: 176回
紹介文 :
ユーザーが陥ってしまう操作上での行き詰まりに対して、行為の7段階モデルを元に時系列をさかのぼって分析することで、より本質的な原因を探っています。 この方法を用いることで、ユーザーの心理や行動、認識まで意識することができるため、なぜなぜ分析単独では見つけにくい真因を見つけることができます。
ダウンロード数: 145回
SQuBOK分類 :
1.1.4  使用性
紹介文 :
商品企画段階においてユーザ要求の本質を分析する手法として、HCD(Human-centred Design)の適用のメリットを説明し、その主要な手法であるペルソナ法、シナリオ法をとり上げ、その適用方法を説明している。また、その適用によって作成した要求仕様を、ペーパプロトタイピング手法により検証し、改善点を洗い出した。 HCD適用しない場合の要求定義と、HCDを適用した場合の要求定義の差異が報告されている。
ダウンロード数: 139回
紹介文 :
専門的なソフトウェアについて、利用者も気づいていない要求を抽出するために、該当ソフトウェアの初心者が熟練者に弟子入りして学ぶ様子を観察しています。 要求を実現する画面案と実機を組み合わせた簡易プロトタイプで評価することで、要求の妥当性検証を短期間・低コストで実施できるよう工夫されています。
ダウンロード数: 132回
紹介文 :
ウェブサイトの顔と言えるトップページに着目し、「日本語ウェブサイト向けのトップページ・ユーザビリティ・ガイドライン」を提供しています。業種の特性を考慮した評価項目も追加されており、このガイドラインをベースにして各業種、各企業に合わせてカスタマイズすることでトップページの効果的な評価を行うことができます。
ダウンロード数: 124回
紹介文 :
システムを開発して納品する間際にお客様から「これでは使えない」と言われたことはありませんか? 本論文では、プロジェクトがこのような状況に陥る可能性がないかを「診断」するためのツールと、診断で判明した問題を解決するためのUXデザイン手法がすぐわかる「処方箋」を提案しています。 2つのツールは組み合わせて使用するだけでなく、それぞれ単独で使っても効果が見込めます。 これからUXデザインを学んで実践しようとする方も、実施検討のために活用していただけます。
ダウンロード数: 114回
紹介文 :
ECサイトのベストプラクティスと言えるAmazonサイトの成功要因をユーザビリティの観点から探っています。書籍ECサイトに対するガイドラインによるチェックにより外から見た静的な評価を行ったり、利用者のタスク分析により動的な評価も行うことで多面的にAmazonサイトを分析しています。ちなみに、『Amazon Hacks』と言う書籍の翻訳も研究活動と並行して行うことで、サイトが意図していることや内部の作りについても深く研究を行っています。
ダウンロード数: 101回
紹介文 :
 システムをリリースした後にくるクレームの「言葉」をどのように改修要件に落とし込むかについての研究です。「ぼやき」のような曖昧な言葉を、システム的にどのように解釈すれば良いのかを考察しています。一人でもチームでも運用できるチェックシート形式の問診票で改修の必要度を探ります。ユーザから直接フィードバックを得られる立場の方に、特にお勧めします。
ダウンロード数: 100回
紹介文 :
運用しているWebサイトの使用性(ユーザービリティ)を改善するために、簡易リモートUT(ユーザビリティテスト)を使った素早い課題抽出と、Webサイト目的・利用者ニーズに基づく優先順位づけを提案しています。 UXの専門知識を持たないWeb担当者でも実施可能なやり方になっています。
ダウンロード数: 59回
年度 : 2015年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では機能の変更が中心であり、変更後のテストでも機能のデグレードに目が行きがちで、操作性や使い勝手が変化していることに気づくことは少なく、リリース後に「使いづらくなった」といったクレームが入ることがある。 また、操作に関連した変更の場合も、求められている操作性については確認するが、まったく意識していないところで影響がでることがある。 変更時に参照する機能仕様書や操作仕様書には、ユーザビリティについて詳しく書かれていないが、テストケースには、いろいろなケースが扱われている。 そこで、変更で影響を受けやすいユーザビリティの観点と関連するテストケースを組み合わせて「振る舞いbefore/afterシート」を作ることで、変更に伴うユーザビリティの影響に気づく方法を提供している。 この方法は、普段からテストケースを充実させておくことで対応しやすくなる。
ダウンロード数: 28回
年度 : 2016年   分科会 : 第6分科会「派生開発」
紹介文 :
一般に、派生開発では機能の追加と変更が中心になる。その結果、応答時間などに変化が生じることがある。設計の担当者は応答時間の変化に気づかなかったり、気づいていた時でも、これくらいなら問題ないだろうと勝手に決め込んだりしていることが多く、納品後に「時間効率性」の劣化としてクレームとなる場合がある。時間効率性に関するクレームは、必ずしも遅くなったから問題になるとは限らない。派生開発の場合、使い慣れている状況に対して変化が許容範囲を超えると操作に影響を与えるからである。 設計者が応答時間等の劣化に気づかない理由として、ソースコードの該当箇所を探す際も、機能の変更に気を取られ、その機能が操作と絡んでいることに気がついていないことがある。そこで、変更要求を捉える段階で、メモリー処理や通信処理などの時間効率性に影響を与えそうな機能を変更するときには、時間の変化を予測して、「EMOT(Estimation Method Of Time behavior degradation)」の確認表を使って変化時間の目安を確認する。そこで事前に想定している許容範囲を超える時は、早めに依頼者と変更方法などを協議する。また他に変更方法がない時は、操作側で事前にトレーニングして備えてもらうことになる。こうした対応によって、後からのクレームになることを回避する。
↑