SQuBok(R)分類検索
67 件の資料が見つかりました。
ダウンロード数: 281回
紹介文 :
ソフトウェア開発の現場で起きている失敗の原因とUX手法が解決できる問題を突き合わせることで、現場や問題の状況に合わせて適切なUX手法を選択することを提案している。単に手法ありきで導入するのではなく、本来の目的を把握・意識したうえで、本当に望まれている結果を導くための重要な考え方を提示している。
ダウンロード数: 274回
年度 : 2013年   分科会 :
紹介文 :
非クリティカルシステムの短期開発に取り組むときに、参考になる研究です。QAチームと、開発者、ユーザー、ツールの関わり方についても提案されており、QA担当者だけでなく、開発者やマネージャーにも有用です。 後半には事例紹介もありますので、実際の開発チームやQAチームの動きや効果の詳細を知りたい方にも役立つ内容となっています。
ダウンロード数: 274回
年度 : 2012年   分科会 : 第6分科会「派生開発」
紹介文 :
問題の発生源が組織の役割分担の仕方に起因することが少なくない。しかもその分担方法が「前提」として認識されている場合は、そこに改善の手が入らない。この種の問題は、組織を跨ぐことがあるが、単に役割分担の問題だったりすることもある。 この報告書は、目立たない取り組みだが、問題を分析する過程で、問題の源泉が不適切な慣行にあることに気付いたケースであり、問題を分析することの重要性を示唆している。
ダウンロード数: 261回
年度 : 2013年   分科会 :
紹介文 :
保守プロジェクトの改善の着手や進め方について悩んでいる方、改善のための指標項目の事例を知りたい人に、特に参考になる内容です。 筆者らの施策で設定した目的や指標項目、PDCAサイクルを利用した活動内容にも触れられており、読者自身の現場で使っている指標や活動内容と照らし合わせながら読むことができます。
ダウンロード数: 245回
年度 : 2013年   分科会 :
紹介文 :
「トヨタ開発方式」を用いて、開発管理方法の改善を図る研究です。筆者らが行った活動だけでなく、振り返りや効果測定についても詳しく述べられています。「トヨタ開発方式」だけではなく改善に興味がある方全般に、参考になる内容です。「トヨタ開発方式」については、序盤で概要が説明されており、詳しくない方でも読み進められます。 「トヨタ開発方式」の適用を目指している方、プロセス改善の方法を模索している方に、特にお薦めです。
ダウンロード数: 232回
紹介文 :
ウェブサイトの顔と言えるトップページに着目し、「日本語ウェブサイト向けのトップページ・ユーザビリティ・ガイドライン」を提供しています。業種の特性を考慮した評価項目も追加されており、このガイドラインをベースにして各業種、各企業に合わせてカスタマイズすることでトップページの効果的な評価を行うことができます。
ダウンロード数: 224回
SQuBOK分類 :
1.1.4  使用性
紹介文 :
商品企画段階においてユーザ要求の本質を分析する手法として、HCD(Human-centred Design)の適用のメリットを説明し、その主要な手法であるペルソナ法、シナリオ法をとり上げ、その適用方法を説明している。また、その適用によって作成した要求仕様を、ペーパプロトタイピング手法により検証し、改善点を洗い出した。 HCD適用しない場合の要求定義と、HCDを適用した場合の要求定義の差異が報告されている。
ダウンロード数: 212回
紹介文 :
新しい安全解析手法「STAMP/STPA」にセキュリティ適用をし、 「アシュアランスケース」で分析の妥当性確認をした初めての研究事例です。 脅威にはSTRIDE分析、影響評価基準にはASILを用いました。 保証の全体像を定めた上で、セーフティとセキュリティ双方のリスク抽出、評価、対策まで作り込みました。 「自動運転」での事例はお役立ち間違いなしです!
ダウンロード数: 201回
紹介文 :
ISO9001(2000年版)の認証を取得してる企業がCMM(SW-CMM)の取得を目指すためのガイド。 ISO9001認証後にプロセス改善を行う際にCMMIを参考にする場合にも有効。 ISO9001未取得の企業の場合はIOS9001/CMMの要求から自社の状況で施策のベースを検討するのにも有効である。
ダウンロード数: 196回
紹介文 :
プロジェクトの振り返り”活動結果を、他のプロジェクトでも活用し、反映させ展開することは、実際には難しいという問題がある。  本テーマは、この問題に焦点を当て、展開すべき振り返り結果の改善策(TRY)の納得感を高めるため、振り返り分析プロセスについて、観点シートで網羅的な成功点/問題点(KEEP/PROBLEM)を抽出し、QCD観点から他への展開の重要度が高い問題点を選定して、それを分析シートで真因分析するよう、手を加えることから始め、担当者だけでなく管理者や改善支援担当も含めた展開のための振り返りも行って、改善策の反映プロセスでの情報伝達・実践状況の実行支援の仕組みまでを一貫させて結合しようとする、組織改善に欠かせないプロセス基盤構築の研究である。
ダウンロード数: 190回
紹介文 :
ECサイトのベストプラクティスと言えるAmazonサイトの成功要因をユーザビリティの観点から探っています。書籍ECサイトに対するガイドラインによるチェックにより外から見た静的な評価を行ったり、利用者のタスク分析により動的な評価も行うことで多面的にAmazonサイトを分析しています。ちなみに、『Amazon Hacks』と言う書籍の翻訳も研究活動と並行して行うことで、サイトが意図していることや内部の作りについても深く研究を行っています。
ダウンロード数: 185回
紹介文 :
AI・IoT時代に即した、システムを全体俯瞰でとらえるシステム思考アプローチであるSTAMP (Systems Theoretic Accident Model and Processes)やしなやかな強さで安全性を実現し、回復させるレジリエンス・エンジニアリングが注目されている。 そこで産業総合研究所からだされたサイバーセキュリティ事故報告書に対して、STAMPモデルを用いた事故分析手法CAST(Casual Analysis using System Theory)とレジリエンスエンジニアの機能共鳴手法FRAMの2つの手法による分析を実施し、各手法の特徴を比較した。セーフティ技術であるCASTとFRAMをサイバーセキュリティの分析に用いた点も大変、新規性の高い取り組みである。 論文とともに具体的な分析の一連の証跡、分析手順、結果など、利用価値の高い付録も収録しているので、ぜひ活用してほしい。
ダウンロード数: 184回
紹介文 :
本研究は、品質保証メンバーが客観的役割を基本としつつ、品質保証活動より得られた知見を活かして、開発プロジェクトに積極的に寄り添ってQCD 問題解決を促進する活動の提案である。 調査分析から、開発プロジェクトが品質保証メンバーに期待する支援範囲を抽出し実践した、大変有用性の高い研究である。
ダウンロード数: 170回
紹介文 :
品質の向上とは、究極的には顧客満足度の向上であり、そのためには、組織全体を、顧客に対する新しい価値を創造し、積極的に提案する顧客価値経営に到達させることが必要である。本論文は、「日本経営品質賞」のフレームワークをベースに、顧客価値経営到達への道筋を、具体的改善項目の実施度合により示しており、アセスメントと改善の繰り返しにより組織レベルを向上させることができる点が、有益かつ実践的である。
ダウンロード数: 167回
紹介文 :
製品知識や開発情報・技術のノウハウは特定の担当者によって異なるが、偏りが進み過ぎると、伝達すべき情報や技術が継承されず,製品を改造・流用する際に製品仕様や設計、実装時の検討漏れや誤りなどの原因となって問題を引き起こす場合が多い。  本テーマは、この“いわゆる属人化状態”の分析に焦点を当て、プロジェクトチーム内の担当者同士による技術面での個人依存度の主観的な相互評価の値と、レビュー実施時の各担当者別の発言時間という客観的な測定値とを組み合わせ、担当者を「職人領域」,「属人領域」,「教育領域」,「点検領域」,「適正領域」の五つに分類し、チーム内の担当者の相対的な属人化の進行の不均衡さ(チームバランス)を可視化することによって、 管理者が各領域のバランス状態を確認し、必要な育成リソースに対する過不足を把握して、 問題発生前の事前対応計画作成に役立てられるよう、属人化状態の測定・可視化を通して改善する仕組みを構築しようとする研究である。
ダウンロード数: 167回
紹介文 :
AI/IoT時代の新しい安全分析手法として注目されているSTAMP/STPA (Systems Theoretic Accident Model and Processes / System Theoretic Process Analysis)は、セーフティとセキュリティのリスクを同時分析が可能であることを本分科会では昨年度、初めて提言しました。今年度はSTAMPを用いた場合と用いない場合に分けて、自動運転の利用シーンを具体化した事例による実験を実施し、STAMPによるセーフティセキュリティ分析の有効性を確認しました。 論文とともに具体的な分析の一連の証跡、分析手順、実験の質問事項や結果、用語集など、利用価値の高い付録も収録しています。ぜひご活用ください。
ダウンロード数: 165回
紹介文 :
ソフトウェア開発プロジェクトを円滑に進めるためには、コミュニケーション(情報伝達)は重要な要素である。プロジェクト内で「コミュニケーションに関する問題」が発生すると、プロジェクトは開発現場の諸問題に気づかずに適切に対処しないまま進行しがちとなり、メンバの士気低下やプロジェクト全体の雰囲気が悪化する。これは、さらに潜在する課題の増加を招くので、プロジェクトにとって大きなリスクとなり得る。 そこで本研究では、プロジェクトリーダ、チームリーダ、チームメンバ間のコミュニケーション問題,士気/雰囲気の問題を察知するための質問を「コミュニケーション問診票」として作成し提案し、試行している。そして、「コミュニケーション問診票」を適用して“問題点を検知”し、「コミュニケーション問題箇所特定図」にて“問題点を特定”し、PMOやSQAなどのプロジェクトの第三者の専門部門にて作成された「処方箋」提案をもとに、プロジェクトリーダ、チームリーダ、チームメンバが各範囲で“問題に対処”する流れを体系化した。コミュニケーションの問題は可視化が困難であるが、プロジェクト全体を俯瞰した図を活用し、見える化を図った興味深いテーマである。
ダウンロード数: 156回
紹介文 :
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか? 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。 そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。
ダウンロード数: 139回
年度 : 2015年   分科会 : 第6分科会「派生開発」
紹介文 :
派生開発では機能の変更が中心であり、変更後のテストでも機能のデグレードに目が行きがちで、操作性や使い勝手が変化していることに気づくことは少なく、リリース後に「使いづらくなった」といったクレームが入ることがある。 また、操作に関連した変更の場合も、求められている操作性については確認するが、まったく意識していないところで影響がでることがある。 変更時に参照する機能仕様書や操作仕様書には、ユーザビリティについて詳しく書かれていないが、テストケースには、いろいろなケースが扱われている。 そこで、変更で影響を受けやすいユーザビリティの観点と関連するテストケースを組み合わせて「振る舞いbefore/afterシート」を作ることで、変更に伴うユーザビリティの影響に気づく方法を提供している。 この方法は、普段からテストケースを充実させておくことで対応しやすくなる。
     

1

2

3

4
↑