6 件の資料が見つかりました。
ダウンロード数： 307回
執筆者 :
森 敦 (株式会社インテック)
、竹内 昌幸(エヌ・ティ・ティ・コムウェア株式会社)
、了徳寺 真(株式会社日立ソリューションズ・クリエイト)
、淵野 浩二(エヌ・ティ・ティ・コミュニケーションズ株式会社)
紹介文 :
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか？ 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。
この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか？ 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。
この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。
ダウンロード数： 204回
SQuBOK分類 :
1.2.2 改善の考え方 、 2.3.2.3 ポストモーテム 、 2.3.2 ソフトウェアプロセス改善のためのマネジメント技法 、 2.12.1.2 プロジェクト&プログラムマネジメント（P2M） 、 2.19.2 プロセス品質の分析・評価
1.2.2 改善の考え方 、 2.3.2.3 ポストモーテム 、 2.3.2 ソフトウェアプロセス改善のためのマネジメント技法 、 2.12.1.2 プロジェクト&プログラムマネジメント（P2M） 、 2.19.2 プロセス品質の分析・評価
紹介文 :
プロジェクトの振り返り”活動結果を、他のプロジェクトでも活用し、反映させ展開することは、実際には難しいという問題がある。
本テーマは、この問題に焦点を当て、展開すべき振り返り結果の改善策(TRY)の納得感を高めるため、振り返り分析プロセスについて、観点シートで網羅的な成功点/問題点(KEEP/PROBLEM)を抽出し、QCD観点から他への展開の重要度が高い問題点を選定して、それを分析シートで真因分析するよう、手を加えることから始め、担当者だけでなく管理者や改善支援担当も含めた展開のための振り返りも行って、改善策の反映プロセスでの情報伝達・実践状況の実行支援の仕組みまでを一貫させて結合しようとする、組織改善に欠かせないプロセス基盤構築の研究である。
プロジェクトの振り返り”活動結果を、他のプロジェクトでも活用し、反映させ展開することは、実際には難しいという問題がある。
本テーマは、この問題に焦点を当て、展開すべき振り返り結果の改善策(TRY)の納得感を高めるため、振り返り分析プロセスについて、観点シートで網羅的な成功点/問題点(KEEP/PROBLEM)を抽出し、QCD観点から他への展開の重要度が高い問題点を選定して、それを分析シートで真因分析するよう、手を加えることから始め、担当者だけでなく管理者や改善支援担当も含めた展開のための振り返りも行って、改善策の反映プロセスでの情報伝達・実践状況の実行支援の仕組みまでを一貫させて結合しようとする、組織改善に欠かせないプロセス基盤構築の研究である。
ダウンロード数： 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)」手法を提案しています。
ダウンロード数： 174回
紹介文 :
ソフトウェア開発プロジェクトを円滑に進めるためには、コミュニケーション（情報伝達）は重要な要素である。プロジェクト内で「コミュニケーションに関する問題」が発生すると、プロジェクトは開発現場の諸問題に気づかずに適切に対処しないまま進行しがちとなり、メンバの士気低下やプロジェクト全体の雰囲気が悪化する。これは、さらに潜在する課題の増加を招くので、プロジェクトにとって大きなリスクとなり得る。
そこで本研究では、プロジェクトリーダ、チームリーダ、チームメンバ間のコミュニケーション問題，士気／雰囲気の問題を察知するための質問を「コミュニケーション問診票」として作成し提案し、試行している。そして、「コミュニケーション問診票」を適用して“問題点を検知”し、「コミュニケーション問題箇所特定図」にて“問題点を特定”し、PMOやSQAなどのプロジェクトの第三者の専門部門にて作成された「処方箋」提案をもとに、プロジェクトリーダ、チームリーダ、チームメンバが各範囲で“問題に対処”する流れを体系化した。コミュニケーションの問題は可視化が困難であるが、プロジェクト全体を俯瞰した図を活用し、見える化を図った興味深いテーマである。
ソフトウェア開発プロジェクトを円滑に進めるためには、コミュニケーション（情報伝達）は重要な要素である。プロジェクト内で「コミュニケーションに関する問題」が発生すると、プロジェクトは開発現場の諸問題に気づかずに適切に対処しないまま進行しがちとなり、メンバの士気低下やプロジェクト全体の雰囲気が悪化する。これは、さらに潜在する課題の増加を招くので、プロジェクトにとって大きなリスクとなり得る。
そこで本研究では、プロジェクトリーダ、チームリーダ、チームメンバ間のコミュニケーション問題，士気／雰囲気の問題を察知するための質問を「コミュニケーション問診票」として作成し提案し、試行している。そして、「コミュニケーション問診票」を適用して“問題点を検知”し、「コミュニケーション問題箇所特定図」にて“問題点を特定”し、PMOやSQAなどのプロジェクトの第三者の専門部門にて作成された「処方箋」提案をもとに、プロジェクトリーダ、チームリーダ、チームメンバが各範囲で“問題に対処”する流れを体系化した。コミュニケーションの問題は可視化が困難であるが、プロジェクト全体を俯瞰した図を活用し、見える化を図った興味深いテーマである。
ダウンロード数： 76回
執筆者 :
大釜 俊洋（本田技研工業株式会社）
紹介文 :
ソフトウェア及びシステムのテストでは、市場で発生する可能性のある故障発生数を予測して、テスト完了を判断方法や定量的な基準を明確にすることができていますか？ これらは、特に自動車開発におけるテストで解決が難しい課題となっています。
この論文では、ソフトウェア開発委託取引先からの受入れテスト時に、市場発生する可能発生数の予測をして、テスト完了時期を判断する方法と基準について研究しています。このため、ソフトウェア信頼度成長モデルを用いた故障率の減衰予測と市場使用期間での累積故障発生数を指数関数モデル化した予測とを組み合わせた予測手法を提案・分析しています。さらに、ユースケーステスト結果も追加評価して潜在故障数を予測することによる二重判断、及び受入れテストでの検出故障が収束傾向にない場合の対策として、開発組織の原因分析・対策活動の促進状況の判断も加えて、故障の市場発生数を予想評価してテスト完了時期を判断する包括的な方法（「オーカマモデル」）を提案しています。
ソフトウェア及びシステムのテストでは、市場で発生する可能性のある故障発生数を予測して、テスト完了を判断方法や定量的な基準を明確にすることができていますか？ これらは、特に自動車開発におけるテストで解決が難しい課題となっています。
この論文では、ソフトウェア開発委託取引先からの受入れテスト時に、市場発生する可能発生数の予測をして、テスト完了時期を判断する方法と基準について研究しています。このため、ソフトウェア信頼度成長モデルを用いた故障率の減衰予測と市場使用期間での累積故障発生数を指数関数モデル化した予測とを組み合わせた予測手法を提案・分析しています。さらに、ユースケーステスト結果も追加評価して潜在故障数を予測することによる二重判断、及び受入れテストでの検出故障が収束傾向にない場合の対策として、開発組織の原因分析・対策活動の促進状況の判断も加えて、故障の市場発生数を予想評価してテスト完了時期を判断する包括的な方法（「オーカマモデル」）を提案しています。
