25 件の資料が見つかりました。
ダウンロード数: 302回
SQuBOK分類 :
紹介文 :
日本におけるソフトウェア開発の特徴として,異なる組織や企業に属するメンバで構成された混成チームによる開発がある.混成チームは多くの課題を抱えている.チームを形成し成長させるための支援の弱体化,組織や企業間の文化の違いによる異文化対立,業務請負に対応したコンプライアンスによるコミュニケーションの制約といった課題である.
フェリカネットワークスでは,混成チームにおけるチーム力向上を目指し,メンバ間の仲間意識を高めるチームビルディングと共に,メンバによる問題解決をサポートする取り組みを行ってきた.メンバの意見や提案を聞き,問題解決を支援することを目的として,コンプライアンスを遵守したヒアリングの仕組みをつくった.この仕組みは,プロジェクトマネジャー,コーディネータ,メンバの 3 名で行う「三者ヒアリング」である.三者ヒアリングは,8 年間に渡って定期的に実施してきた.
本論文では,三者ヒアリングの仕組みについて詳細に報告すると共に,ヒアリング記録を基に,ヒアリングの状態をグラフ表現で可視化し,分析する手法を提案する.また,この手法を用いてヒアリングの状態の分類を試みたので,その結果を報告する.
日本におけるソフトウェア開発の特徴として,異なる組織や企業に属するメンバで構成された混成チームによる開発がある.混成チームは多くの課題を抱えている.チームを形成し成長させるための支援の弱体化,組織や企業間の文化の違いによる異文化対立,業務請負に対応したコンプライアンスによるコミュニケーションの制約といった課題である.
フェリカネットワークスでは,混成チームにおけるチーム力向上を目指し,メンバ間の仲間意識を高めるチームビルディングと共に,メンバによる問題解決をサポートする取り組みを行ってきた.メンバの意見や提案を聞き,問題解決を支援することを目的として,コンプライアンスを遵守したヒアリングの仕組みをつくった.この仕組みは,プロジェクトマネジャー,コーディネータ,メンバの 3 名で行う「三者ヒアリング」である.三者ヒアリングは,8 年間に渡って定期的に実施してきた.
本論文では,三者ヒアリングの仕組みについて詳細に報告すると共に,ヒアリング記録を基に,ヒアリングの状態をグラフ表現で可視化し,分析する手法を提案する.また,この手法を用いてヒアリングの状態の分類を試みたので,その結果を報告する.
ダウンロード数: 279回
SQuBOK分類 :
執筆者 :
星名 卓郎(㈱日立製作所)
紹介文 :
ソフトウェアのテストは設計段階に作成した仕様書をベースに実施されるテストが多くの割合を占めているが、市場不具合の多くは仕様書記載外の問題に起因して発生している傾向が見えている。
我々の事業部では設計・コーディング・テストなどの開発作業を実施する開発部署とは独立した組織として品質保証部があり、開発部署の全工程完了後に出荷可否の判断として最終的な製品検査を実施している。
実際の製品検査で摘出された問題点をみたところと、仕様書記載外の問題点が多く摘出されているが、テスト項目自体は仕様書ベースのものが大半を占めていた。
以上から、仕様書ベースのテスト項目であっても、偶発的な何らかの条件が加わることで、仕様書記載外の問題点を摘出できているのではと考えた。
そこで、製品検査で仕様書記載外の問題を摘出したテスト観点やテスト項目の分析を実施した。
その結果、仕様書記載外の問題を摘出するためのテスト観点として設計段階で考慮すべき観点とテストの実行段階で考慮すべき観点があることが分かった。
これらの分析結果を踏まえ、仕様書記載外の問題を効果的に摘出するための観点を纏めることを考えた。
今回は、実際に発生した市場不具合の起因となった問題点から、当該問題を摘出するために必要だったテスト観点を教訓集として纏めた。
本発表では、以上の分析の流れや、得られた考察、そして作成した教訓集を実際の製品検査に適用した結果を報告する。
ソフトウェアのテストは設計段階に作成した仕様書をベースに実施されるテストが多くの割合を占めているが、市場不具合の多くは仕様書記載外の問題に起因して発生している傾向が見えている。
我々の事業部では設計・コーディング・テストなどの開発作業を実施する開発部署とは独立した組織として品質保証部があり、開発部署の全工程完了後に出荷可否の判断として最終的な製品検査を実施している。
実際の製品検査で摘出された問題点をみたところと、仕様書記載外の問題点が多く摘出されているが、テスト項目自体は仕様書ベースのものが大半を占めていた。
以上から、仕様書ベースのテスト項目であっても、偶発的な何らかの条件が加わることで、仕様書記載外の問題点を摘出できているのではと考えた。
そこで、製品検査で仕様書記載外の問題を摘出したテスト観点やテスト項目の分析を実施した。
その結果、仕様書記載外の問題を摘出するためのテスト観点として設計段階で考慮すべき観点とテストの実行段階で考慮すべき観点があることが分かった。
これらの分析結果を踏まえ、仕様書記載外の問題を効果的に摘出するための観点を纏めることを考えた。
今回は、実際に発生した市場不具合の起因となった問題点から、当該問題を摘出するために必要だったテスト観点を教訓集として纏めた。
本発表では、以上の分析の流れや、得られた考察、そして作成した教訓集を実際の製品検査に適用した結果を報告する。
ダウンロード数: 274回
SQuBOK分類 :
紹介文 :
本発表では、弊社移動機開発部における2013年以来の開発管理プロセスの改善活動について紹介する。
2013年当時、弊社スマートホン向けアプリケーション開発は早期リリース・マルチベンダ化が急速に進んだことで、プロセス整備が追い付かず、開発管理は部内各開発担当者・各ベンダに依存し統一性なく属人的なものとなっていた。また、リリース判定においても開発管理情報の相違から報告内容にバラツキがあり、第三者による品質判定の客観性・統一性向上も解決すべき大きな課題であった。
そこで、部内のプロセス改善チームにて、開発管理報告及びリリース判定時のソフトウェア品質報告の統一様式を作成し、全開発現場に導入した。また、開発現場に密着した人的支援、独自に構築したツールによる支援、現場の意見を取り入れた様式の継続的な改善等により、統一様式による客観的で定量的な指標を用いた開発管理が定着した。
これらの活動の結果、開発管理の精度が向上し、進捗遅延の減少・ソフトウェア品質の向上等の一定の成果を上げることが出来た。また、リリース判定様式の統一により、全プロジェクトを横並び・時系列で品質判定可能となり、客観的な品質判定プロセスを実現した。
本発表では、開発現場への改善施策定着に配慮したプロセス改善活動の内容や工夫した点について紹介する。
本発表では、弊社移動機開発部における2013年以来の開発管理プロセスの改善活動について紹介する。
2013年当時、弊社スマートホン向けアプリケーション開発は早期リリース・マルチベンダ化が急速に進んだことで、プロセス整備が追い付かず、開発管理は部内各開発担当者・各ベンダに依存し統一性なく属人的なものとなっていた。また、リリース判定においても開発管理情報の相違から報告内容にバラツキがあり、第三者による品質判定の客観性・統一性向上も解決すべき大きな課題であった。
そこで、部内のプロセス改善チームにて、開発管理報告及びリリース判定時のソフトウェア品質報告の統一様式を作成し、全開発現場に導入した。また、開発現場に密着した人的支援、独自に構築したツールによる支援、現場の意見を取り入れた様式の継続的な改善等により、統一様式による客観的で定量的な指標を用いた開発管理が定着した。
これらの活動の結果、開発管理の精度が向上し、進捗遅延の減少・ソフトウェア品質の向上等の一定の成果を上げることが出来た。また、リリース判定様式の統一により、全プロジェクトを横並び・時系列で品質判定可能となり、客観的な品質判定プロセスを実現した。
本発表では、開発現場への改善施策定着に配慮したプロセス改善活動の内容や工夫した点について紹介する。
ダウンロード数: 200回
SQuBOK分類 :
紹介文 :
企業のソフトウェア開発現場では、ある一定の品質管理基準を設けて達成すべき品質目標に向けて改善を行うことが一般的である。
しかしながら、基準達成を阻害するソフトウェア欠陥に対しては、何が欠陥であるか欠陥でないかの基準や回避方法が明確に示されないことも多く、品質の確保や改善を難しくしている現実がある。
本研究では、欠陥の定義を明確化するための特性として「基本特性」、また欠陥が混入してから獲得した性質を「混入特性」として整理した「欠陥特性」を提案する。
こうした欠陥が本来持つ性質を正確に定義し、それを踏まえた上での改善活動は、概念だけで語られるような議論を抑制し、現場の実態にあった適切な活動につながることが期待できる。
欠陥特性の有効性検証として、欠陥に対する認識共有の改善と、特性を利用した改善施策の評価を行った結果、提案する欠陥特性の有効性を確認した。本発表では、抽象的な概念である欠陥特性に対してなるべく具体的な事例と、従来の欠陥分類法とのアプローチの違いについて説明する。
企業のソフトウェア開発現場では、ある一定の品質管理基準を設けて達成すべき品質目標に向けて改善を行うことが一般的である。
しかしながら、基準達成を阻害するソフトウェア欠陥に対しては、何が欠陥であるか欠陥でないかの基準や回避方法が明確に示されないことも多く、品質の確保や改善を難しくしている現実がある。
本研究では、欠陥の定義を明確化するための特性として「基本特性」、また欠陥が混入してから獲得した性質を「混入特性」として整理した「欠陥特性」を提案する。
こうした欠陥が本来持つ性質を正確に定義し、それを踏まえた上での改善活動は、概念だけで語られるような議論を抑制し、現場の実態にあった適切な活動につながることが期待できる。
欠陥特性の有効性検証として、欠陥に対する認識共有の改善と、特性を利用した改善施策の評価を行った結果、提案する欠陥特性の有効性を確認した。本発表では、抽象的な概念である欠陥特性に対してなるべく具体的な事例と、従来の欠陥分類法とのアプローチの違いについて説明する。
ダウンロード数: 197回
SQuBOK分類 :
紹介文 :
ソフトウェアの開発現場では,要求や仕様を伝える文書や,プロジェクトのメンバや外部に向けて業務の流れを説明する資料を用いている.要求や仕様,業務処理を文書で伝達する際に,認識のずれや記述不足があると,誤解や処理の抜けなど,コミュニケーションエラーによる手戻りが発生する.
本論文では,文章と図や表で構成された情報伝達型文書の曖昧さの問題に対して,書き手が主体的にコミュニケーションエラーになりうる箇所を検知するための「W検法」を提案する.
W検法は文書作成の最後,あるいは途中の段階で,厳密に仕様を記述するための形式仕様記述 VDM を組み合わせることで,文書の曖昧さを検知する手法である.
本論文では,実際の業務説明文書を題材として,W検法を行うことで形式仕様記述の初学者でも,書き手が自律的に曖昧さを検知できることを確認した.
ソフトウェアの開発現場では,要求や仕様を伝える文書や,プロジェクトのメンバや外部に向けて業務の流れを説明する資料を用いている.要求や仕様,業務処理を文書で伝達する際に,認識のずれや記述不足があると,誤解や処理の抜けなど,コミュニケーションエラーによる手戻りが発生する.
本論文では,文章と図や表で構成された情報伝達型文書の曖昧さの問題に対して,書き手が主体的にコミュニケーションエラーになりうる箇所を検知するための「W検法」を提案する.
W検法は文書作成の最後,あるいは途中の段階で,厳密に仕様を記述するための形式仕様記述 VDM を組み合わせることで,文書の曖昧さを検知する手法である.
本論文では,実際の業務説明文書を題材として,W検法を行うことで形式仕様記述の初学者でも,書き手が自律的に曖昧さを検知できることを確認した.
1 | 2 |