15 件の資料が見つかりました。
ダウンロード数: 2864回
SQuBOK分類 :
1.1.1 品質の定義(品質の考え方の変遷) 、 1.3.1 プロダクト品質とプロセス品質 、 2.3.1.1 CMMI(能力成熟度モデル統合) 、 2.3.2.1 プロセスアセスメントに関する規格(ISO/IEC 15504)
1.1.1 品質の定義(品質の考え方の変遷) 、 1.3.1 プロダクト品質とプロセス品質 、 2.3.1.1 CMMI(能力成熟度モデル統合) 、 2.3.2.1 プロセスアセスメントに関する規格(ISO/IEC 15504)
紹介文 :
組み込み系における品質活動特にSQAに関する責任と権限を明確にして活動を行うことのヒント。組み込み製品のジャンル分けをしてプロセスの特徴を整理しどのような観点でプロセスチェックを行うべきかをヒント。等を研究しSQAの活動を報告されている。
組み込み系における品質活動特にSQAに関する責任と権限を明確にして活動を行うことのヒント。組み込み製品のジャンル分けをしてプロセスの特徴を整理しどのような観点でプロセスチェックを行うべきかをヒント。等を研究しSQAの活動を報告されている。
ダウンロード数: 2375回
SQuBOK分類 :
1.1.2.1 システム/ソフトウェア製品の品質モデル(ISO/IEC 25000シリーズ) 、 1.3.1 プロダクト品質とプロセス品質 、 2.3.1.1 CMMI(能力成熟度モデル統合) 、 2.19 品質分析・評価のマネジメント
1.1.2.1 システム/ソフトウェア製品の品質モデル(ISO/IEC 25000シリーズ) 、 1.3.1 プロダクト品質とプロセス品質 、 2.3.1.1 CMMI(能力成熟度モデル統合) 、 2.19 品質分析・評価のマネジメント
執筆者 :
篠田 みゆき(TIS)
、石田 芳昭(野村総合研究所)
、渡邊 泰史(NTT データ)
、小堺 大亮(Samsung Electronics)
、富本 達明(三菱電機マイコン機器ソフトウエア)
紹介文 :
ソフトウェア成果物の品質を測定する際の、①プロセスに着目した評価方法と②プロダクトの品質特性に着目した評価方法の両面について整理し、開発現場で実践的に活用できる分析方法を提案しています。
ソフトウェア成果物の品質を測定する際の、①プロセスに着目した評価方法と②プロダクトの品質特性に着目した評価方法の両面について整理し、開発現場で実践的に活用できる分析方法を提案しています。
ダウンロード数: 1142回
SQuBOK分類 :
1.1.1 品質の定義(品質の考え方の変遷) 、 1.3.4 システム及びソフトウェア評価の考え方 、 2.14 要求分析のマネジメント 、 2.19.1 プロダクト品質の分析・評価 、 3.5 要求分析の技法
1.1.1 品質の定義(品質の考え方の変遷) 、 1.3.4 システム及びソフトウェア評価の考え方 、 2.14 要求分析のマネジメント 、 2.19.1 プロダクト品質の分析・評価 、 3.5 要求分析の技法
執筆者 :
鈴木 三紀夫 (TIS)
、藤村 紫一郎(NTTソフトウェア)
、神谷 造(NTTコムウェア)
、湯川 洋一郎(NTTデータ)
、東条 宏(TIS)
、村岡 政海(NTTコムウェア)
、日比野 昌司(山武ビルシステム)
、山本 拓雄(日本タイムシェア)
、大須賀 敏彦(NTTコムウェア)
、坂口 賢一(ユー・エス・イー)
、佐賀 桂(アドイン研究所)
紹介文 :
2001年時点での「創造的なシステム開発」の方法(=情報システムにおける要求分析の方法)について述べている。論点は、情報システム発注者の「欲しいもの」だけでなく、発注者の先にいる利用者の「欲しいはずのもの」までを捕えるというところにある。この考え方は、2013年時点では当たり前になっているが、実現の度合いから言うと難しい問題として残っている。
2001年時点での「創造的なシステム開発」の方法(=情報システムにおける要求分析の方法)について述べている。論点は、情報システム発注者の「欲しいもの」だけでなく、発注者の先にいる利用者の「欲しいはずのもの」までを捕えるというところにある。この考え方は、2013年時点では当たり前になっているが、実現の度合いから言うと難しい問題として残っている。
ダウンロード数: 1078回
紹介文 :
現状アジャイル開発でウォータフォールと同じような品質保証活動を行うと、過大な工数がかかるか、品質保証活動が開発の終盤になってしまう。 この課題を解決するために、品質保証部門のみによる監査ではなく、開発現場自身がセルフチェックを行うことで相乗効果を狙うアプローチを「QAAD42」(Quality Assurance in Agile Development by 42)と命名し検証を実施し、その効果を確認した。
現状アジャイル開発でウォータフォールと同じような品質保証活動を行うと、過大な工数がかかるか、品質保証活動が開発の終盤になってしまう。 この課題を解決するために、品質保証部門のみによる監査ではなく、開発現場自身がセルフチェックを行うことで相乗効果を狙うアプローチを「QAAD42」(Quality Assurance in Agile Development by 42)と命名し検証を実施し、その効果を確認した。
ダウンロード数: 704回
SQuBOK分類 :
1.1.1.9 品質の定義(狩野紀昭) 、 1.3.5.2 妥当性確認(Validation) 、 2.2.3.3 プロトタイピング 、 2.8 意思決定のマネジメント 、 3.13 使用性の技法
1.1.1.9 品質の定義(狩野紀昭) 、 1.3.5.2 妥当性確認(Validation) 、 2.2.3.3 プロトタイピング 、 2.8 意思決定のマネジメント 、 3.13 使用性の技法
紹介文 :
エンジニアからアイデアを引き出すための手順としての研究です。アイデアは時流にのった旬が大切ですが、採用/不採用に関わらず選定者の観点や責任問題が気になります。最低限何を提出してもらい、どんな観点でレビューすれば良いのかで悩んでいる方にお勧めします。
エンジニアからアイデアを引き出すための手順としての研究です。アイデアは時流にのった旬が大切ですが、採用/不採用に関わらず選定者の観点や責任問題が気になります。最低限何を提出してもらい、どんな観点でレビューすれば良いのかで悩んでいる方にお勧めします。
ダウンロード数: 588回
執筆者 :
藤貫 美佐(NTTデータ)
、渡辺 絢子(NTTデータ)
、渡辺 真太郎(NTTデータ)
、木谷 強(NTTデータ)
、戸村 元久(NTTデータ)
、大杉 直樹(NTTデータ)
、伏田 享平(NTTデータ)
、井ノ口 伸人(NTTデータ)
紹介文 :
システム基盤の構築に要する工数見積もりに関する取組みは少ないものです。国内外の学術機構や企業における事例報告においても十分とは言えません。 そこで、非機能要求のコストに影響にする変数をコストドライバとして定義し定量化を試み、見積もりモデルの有意性を実績との比較で検証し評価しています。 そして、この見積もりモデルをWebツールとして社内展開し運用しています。
システム基盤の構築に要する工数見積もりに関する取組みは少ないものです。国内外の学術機構や企業における事例報告においても十分とは言えません。 そこで、非機能要求のコストに影響にする変数をコストドライバとして定義し定量化を試み、見積もりモデルの有意性を実績との比較で検証し評価しています。 そして、この見積もりモデルをWebツールとして社内展開し運用しています。
ダウンロード数: 449回
紹介文 :
プロジェクトデータの測定と分析について悩みを持つ組織は数多くあります。また、データ活用ができるかどうかによって、プロセス改善の効果や継続性が左右されるといっても過言ではありません。この論文は研究員企業で用いられているメトリクスについて活用方法、利用者、その効果を幅広く調査しまとめています。また、同様の研究テーマを取り扱った過去の研究成果と比較し傾向をまとめるなど、開発現場が実施しやすく効果の高いメトリクスを検討する場合に参考になります。
プロジェクトデータの測定と分析について悩みを持つ組織は数多くあります。また、データ活用ができるかどうかによって、プロセス改善の効果や継続性が左右されるといっても過言ではありません。この論文は研究員企業で用いられているメトリクスについて活用方法、利用者、その効果を幅広く調査しまとめています。また、同様の研究テーマを取り扱った過去の研究成果と比較し傾向をまとめるなど、開発現場が実施しやすく効果の高いメトリクスを検討する場合に参考になります。
ダウンロード数: 419回
紹介文 :
開発工程にて用いられるW字モデルを品質保証部門における検査プロセスに適用させ、検査プロセスのプロセス改善に取り組んだ事例を紹介しています。品質保証工程において機能仕様書に記載される機能に対する検査観点をまとめた検査観点表をW字モデルにおける上流工程で作成することにより機能仕様の不備やテスト項目の不足を洗出しバグ摘出数の向上とバグ修正工数の短縮につなげています。
開発工程にて用いられるW字モデルを品質保証部門における検査プロセスに適用させ、検査プロセスのプロセス改善に取り組んだ事例を紹介しています。品質保証工程において機能仕様書に記載される機能に対する検査観点をまとめた検査観点表をW字モデルにおける上流工程で作成することにより機能仕様の不備やテスト項目の不足を洗出しバグ摘出数の向上とバグ修正工数の短縮につなげています。
ダウンロード数: 364回
SQuBOK分類 :
1.1.1.9 品質の定義(狩野紀昭) 、 1.3.5.2 妥当性確認(Validation) 、 2.14.2 要求の妥当性確認と評価 、 3.5 要求分析の技法 、 3.13.1.2 インタラクティブシステムの人間中心設計プロセス(ISO 9241-210)
1.1.1.9 品質の定義(狩野紀昭) 、 1.3.5.2 妥当性確認(Validation) 、 2.14.2 要求の妥当性確認と評価 、 3.5 要求分析の技法 、 3.13.1.2 インタラクティブシステムの人間中心設計プロセス(ISO 9241-210)
紹介文 :
要件定義段階で顧客・ユーザとの認識の齟齬を減らすには、UX手法が効果的ですが、 開発現場で導入するにはまだまだ敷居が高い状況です。しかし、従来のやり方や設計書の 書式を大きく変えなくても、要件定義時に5W1Hを考慮するというちょっとした工夫を 加えるだけで、要件の齟齬や漏れを減らす効果があります。 またスマートスピーカーを題材にした検証結果も掲載されており、実践の参考になります。
要件定義段階で顧客・ユーザとの認識の齟齬を減らすには、UX手法が効果的ですが、 開発現場で導入するにはまだまだ敷居が高い状況です。しかし、従来のやり方や設計書の 書式を大きく変えなくても、要件定義時に5W1Hを考慮するというちょっとした工夫を 加えるだけで、要件の齟齬や漏れを減らす効果があります。 またスマートスピーカーを題材にした検証結果も掲載されており、実践の参考になります。
ダウンロード数: 311回
SQuBOK分類 :
1.1.4 使用性 、 1.3.5 V&V(Verification & Validation) 、 3.5.1.1 ステークホルダー識別 、 3.5.1.2 要求開発(Openthology) 、 3.9.5 利用に基づいた技法 、 3.13.1.1 ユーザビリティテスト
1.1.4 使用性 、 1.3.5 V&V(Verification & Validation) 、 3.5.1.1 ステークホルダー識別 、 3.5.1.2 要求開発(Openthology) 、 3.9.5 利用に基づいた技法 、 3.13.1.1 ユーザビリティテスト
執筆者 :
谷 真裕(インテック)
、田村 善嗣(NTTコムウェア)
、田中 崇(インテック)
、清水 里美(旭化成)
、森下 栄治(インテック)
、大沼 恵里奈(東京海上日動システムズ)
、中島 碧莉(インテック)
紹介文 :
システムを開発して納品する間際にお客様から「これでは使えない」と言われたことはありませんか? 本論文では、プロジェクトがこのような状況に陥る可能性がないかを「診断」するためのツールと、診断で判明した問題を解決するためのUXデザイン手法がすぐわかる「処方箋」を提案しています。 2つのツールは組み合わせて使用するだけでなく、それぞれ単独で使っても効果が見込めます。 これからUXデザインを学んで実践しようとする方も、実施検討のために活用していただけます。
システムを開発して納品する間際にお客様から「これでは使えない」と言われたことはありませんか? 本論文では、プロジェクトがこのような状況に陥る可能性がないかを「診断」するためのツールと、診断で判明した問題を解決するためのUXデザイン手法がすぐわかる「処方箋」を提案しています。 2つのツールは組み合わせて使用するだけでなく、それぞれ単独で使っても効果が見込めます。 これからUXデザインを学んで実践しようとする方も、実施検討のために活用していただけます。
ダウンロード数: 307回
執筆者 :
竹内 昌幸(エヌ・ティ・ティ・コムウェア株式会社)
、淵野 浩二(エヌ・ティ・ティ・コミュニケーションズ株式会社)
、森 敦 (株式会社インテック)
、了徳寺 真(株式会社日立ソリューションズ・クリエイト)
紹介文 :
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか? 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。 この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか? 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。 この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。
ダウンロード数: 287回
SQuBOK分類 :
1.3.5.2 妥当性確認(Validation) 、 2.2.3.3 プロトタイピング 、 2.14.2 要求の妥当性確認と評価 、 3.5.1.1 ステークホルダー識別 、 3.13.1.1 ユーザビリティテスト
1.3.5.2 妥当性確認(Validation) 、 2.2.3.3 プロトタイピング 、 2.14.2 要求の妥当性確認と評価 、 3.5.1.1 ステークホルダー識別 、 3.13.1.1 ユーザビリティテスト
紹介文 :
ソフトウェア開発の現場で起きている失敗の原因とUX手法が解決できる問題を突き合わせることで、現場や問題の状況に合わせて適切なUX手法を選択することを提案している。単に手法ありきで導入するのではなく、本来の目的を把握・意識したうえで、本当に望まれている結果を導くための重要な考え方を提示している。
ソフトウェア開発の現場で起きている失敗の原因とUX手法が解決できる問題を突き合わせることで、現場や問題の状況に合わせて適切なUX手法を選択することを提案している。単に手法ありきで導入するのではなく、本来の目的を把握・意識したうえで、本当に望まれている結果を導くための重要な考え方を提示している。
ダウンロード数: 194回
SQuBOK分類 :
1.2.2.1 PDCA 、 1.2.2.2 改善(KAIZEN) 、 1.2.2 改善の考え方 、 1.3.1 プロダクト品質とプロセス品質 、 2.5.1.2 ソフトウェア開発における監査
1.2.2.1 PDCA 、 1.2.2.2 改善(KAIZEN) 、 1.2.2 改善の考え方 、 1.3.1 プロダクト品質とプロセス品質 、 2.5.1.2 ソフトウェア開発における監査
紹介文 :
本研究は、品質保証メンバーが客観的役割を基本としつつ、品質保証活動より得られた知見を活かして、開発プロジェクトに積極的に寄り添ってQCD 問題解決を促進する活動の提案である。 調査分析から、開発プロジェクトが品質保証メンバーに期待する支援範囲を抽出し実践した、大変有用性の高い研究である。
本研究は、品質保証メンバーが客観的役割を基本としつつ、品質保証活動より得られた知見を活かして、開発プロジェクトに積極的に寄り添ってQCD 問題解決を促進する活動の提案である。 調査分析から、開発プロジェクトが品質保証メンバーに期待する支援範囲を抽出し実践した、大変有用性の高い研究である。
ダウンロード数: 175回
SQuBOK分類 :
1.3.1 プロダクト品質とプロセス品質 、 2.11.3 不具合管理 、 2.19 品質分析・評価のマネジメント 、 3.8 レビューの技法 、 3.10.3 障害分析に関する技法
1.3.1 プロダクト品質とプロセス品質 、 2.11.3 不具合管理 、 2.19 品質分析・評価のマネジメント 、 3.8 レビューの技法 、 3.10.3 障害分析に関する技法
執筆者 :
藤本 勝裕(日本電気株式会社)
、磯野 広太(株式会社インテック)
、牛込 敦(株式会社日立ソリューションズ・クリエイト)
、大釜 俊洋(本田技研工業株式会社)
、喜田 靖人(キヤノン株式会社)
、児島 由希子(SCSK 株式会社)
紹介文 :
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか? 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。 そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか? 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。 そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。
ダウンロード数: 128回
SQuBOK分類 :
1.3.1 プロダクト品質とプロセス品質 、 2.3 ソフトウェアプロセス改善のマネジメント 、 2.6.2.2 動機付け 、 2.19 品質分析・評価のマネジメント 、 3.8 レビューの技法
1.3.1 プロダクト品質とプロセス品質 、 2.3 ソフトウェアプロセス改善のマネジメント 、 2.6.2.2 動機付け 、 2.19 品質分析・評価のマネジメント 、 3.8 レビューの技法
紹介文 :
本論文では,多くのソフトウェア開発現場で作成・運用されている「チェックリ スト(チェックシート)」の改善を目指した,「Smile - Process for Checklist Design (S-PCD)」法を提案している。 チェックリストが,チェックを実施する使用者にとっては分かりにくく,チェッ ク作業の効率が良くないものであることが多い。チェックする目的や内容が曖昧で あったり,項目数が必要以上に多いためである。こうした原因がチェックリストを 作成する手法と体系化にあると分析し,チェックリストを改善するために,チェッ クリストの要件定義・設計プロセスをS-PCD法として定義し提案している。 S-PCD法により、使用者がチェック作業を効率良く行え,ソフトウェア品質向上 に効果があることを実感し,「Smile」を浮かべて作業できるようになり,開発現 場のモチベーションアップに貢献することが期待される。
本論文では,多くのソフトウェア開発現場で作成・運用されている「チェックリ スト(チェックシート)」の改善を目指した,「Smile - Process for Checklist Design (S-PCD)」法を提案している。 チェックリストが,チェックを実施する使用者にとっては分かりにくく,チェッ ク作業の効率が良くないものであることが多い。チェックする目的や内容が曖昧で あったり,項目数が必要以上に多いためである。こうした原因がチェックリストを 作成する手法と体系化にあると分析し,チェックリストを改善するために,チェッ クリストの要件定義・設計プロセスをS-PCD法として定義し提案している。 S-PCD法により、使用者がチェック作業を効率良く行え,ソフトウェア品質向上 に効果があることを実感し,「Smile」を浮かべて作業できるようになり,開発現 場のモチベーションアップに貢献することが期待される。