54 件の資料が見つかりました。
ダウンロード数： 484回
紹介文 :
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人（熟練者）」に依存することが多いが、この研究では、共通仕様に関する変更情報を１箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人（熟練者）」に依存することが多いが、この研究では、共通仕様に関する変更情報を１箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。
ダウンロード数： 434回
執筆者 :
天野 佑太（日立メディコ）
、朝永 糸子（東京海上日動システムズ）
、森崎 一邦（東芝電波システムエンジニアリング）
、上田 克則（大和コンピューター）
、近江 久美子（ＴＩＳ）
、永田 敦（ソニー）
、伊藤 慈朗（東芝デジタルメディアエンジニアリング）
、阿部 修久（キヤノンＩＴソリューションズ）
紹介文 :
「開発の上流文書の質が良くないと下流のテストがタイヘンになる、だったらテストエンジニアが上流から関わってはどうか」というところから出発した報告です。テストエンジニアの視点は設計者や開発者とは異なることを利用し、テストで発見されるべきバグを要求仕様書の段階で見つける試みです。 設計・開発とテスト担当者が別のチームであるプロジェクトなどには、有効な考え方です。
「開発の上流文書の質が良くないと下流のテストがタイヘンになる、だったらテストエンジニアが上流から関わってはどうか」というところから出発した報告です。テストエンジニアの視点は設計者や開発者とは異なることを利用し、テストで発見されるべきバグを要求仕様書の段階で見つける試みです。 設計・開発とテスト担当者が別のチームであるプロジェクトなどには、有効な考え方です。
ダウンロード数： 415回
紹介文 :
増加する派生開発の案件に対応するために、既存の協力会社では間に合わず、新たに外部の協力会社を頼む必要が生じることがある。しかしながら新たに参加する協力会社の技術者には、今回の開発製品やシステムに対するベースの知識が不足していたり、ソースコードの設計の隠れた情報を「読み取るスキル」が不足していたりするため、変更への対応ミスが生じやすい。短い開発期間の中で、このギャップをどのように埋めるかという問題は、多くの現場に共通する問題と思われる。 従来から変更に関連する情報を提供していたが、渡した資料の範囲が広すぎたりしてうまく活用されなかった。その解決方法として、機能と資料とのマトリクスの中で関係情報の所在を示すと同時に、関連する情報を小さな短冊（Chips）にして、目的の箇所に辿りやすくなるように工夫した。マトリクスのマスター情報に対して、今回の変更に関係する箇所がわかるように更新して渡すことで、時間の無駄も省いた。
増加する派生開発の案件に対応するために、既存の協力会社では間に合わず、新たに外部の協力会社を頼む必要が生じることがある。しかしながら新たに参加する協力会社の技術者には、今回の開発製品やシステムに対するベースの知識が不足していたり、ソースコードの設計の隠れた情報を「読み取るスキル」が不足していたりするため、変更への対応ミスが生じやすい。短い開発期間の中で、このギャップをどのように埋めるかという問題は、多くの現場に共通する問題と思われる。 従来から変更に関連する情報を提供していたが、渡した資料の範囲が広すぎたりしてうまく活用されなかった。その解決方法として、機能と資料とのマトリクスの中で関係情報の所在を示すと同時に、関連する情報を小さな短冊（Chips）にして、目的の箇所に辿りやすくなるように工夫した。マトリクスのマスター情報に対して、今回の変更に関係する箇所がわかるように更新して渡すことで、時間の無駄も省いた。
ダウンロード数： 402回
SQuBOK分類 :
2.2.3.5 アジャイル開発 、 2.2 ライフサイクルプロセスのマネジメント 、 2.12 プロジェクトマネジメント 、 2.19 品質分析・評価のマネジメント 、 3.1 メトリクス
2.2.3.5 アジャイル開発 、 2.2 ライフサイクルプロセスのマネジメント 、 2.12 プロジェクトマネジメント 、 2.19 品質分析・評価のマネジメント 、 3.1 メトリクス
執筆者 :
内山 哲三（ビジネスキューブ・アンド・パートナーズ）
、田中 桂三（オムロン）
、森内 真人（インテック）
、山本 和紀（システムソフィア）
、海野 和由（矢崎総業）
、磯貝 竜太（ソフトフロント）
紹介文 :
アジャイル開発手法「スクラム」を用いた開発プロジェクトでは、プロダクトオーナー(PO)から見ると、反復開発するスプリント毎では順調に思えたのが、実は開発状況をうまく把握できていなかったために、品質(Quality) ，コスト(Cost) ，納期(Delivery)の問題が開発プロジェクトの後半に発覚することも少なくありません。 そこで、各スプリントと開発プロジェクト全体の問題を可視化し、POがQCD問題の予兆を察知して対策するきっかけを掴めるような「勘所性」のあるメトリクスを提案しています。プロダクト品質の技術面とプロジェクト管理面から絞り込んだ１７種のメトリクスで、開発プロジェクトのメンバからの有益性、実現可能性の評価についても調査しています。
アジャイル開発手法「スクラム」を用いた開発プロジェクトでは、プロダクトオーナー(PO)から見ると、反復開発するスプリント毎では順調に思えたのが、実は開発状況をうまく把握できていなかったために、品質(Quality) ，コスト(Cost) ，納期(Delivery)の問題が開発プロジェクトの後半に発覚することも少なくありません。 そこで、各スプリントと開発プロジェクト全体の問題を可視化し、POがQCD問題の予兆を察知して対策するきっかけを掴めるような「勘所性」のあるメトリクスを提案しています。プロダクト品質の技術面とプロジェクト管理面から絞り込んだ１７種のメトリクスで、開発プロジェクトのメンバからの有益性、実現可能性の評価についても調査しています。
ダウンロード数： 352回
SQuBOK分類 :
2.2.3.2 反復型開発プロセス 、 2.2.3 プロセスモデル 、 2.18.1.4 V字モデル（Vモデル） 、 3.6.2.1 テスト駆動開発 、 3.7.1.2 リファクタリング
2.2.3.2 反復型開発プロセス 、 2.2.3 プロセスモデル 、 2.18.1.4 V字モデル（Vモデル） 、 3.6.2.1 テスト駆動開発 、 3.7.1.2 リファクタリング
執筆者 :
水野 雄輔（デンソー）
紹介文 :
エンジン制御器（コントローラ）開発においてモデルベース開発（MBD）を導入することにより開発期間の短縮は実現できましたが開発プロセス後半の開発効率の低下は改善できなかったことからMBDの開発プロセスを見直しを行い、ソフトウェア構造と制御対象（プラント）に着目し、シミュレーションを用いるテスト駆動開発を取り入れたプロセス改善方法について提案しています。発表内容はエンジン制御に特化していますが、他の制御機器にも適用できる開発プロセスだと思います。
エンジン制御器（コントローラ）開発においてモデルベース開発（MBD）を導入することにより開発期間の短縮は実現できましたが開発プロセス後半の開発効率の低下は改善できなかったことからMBDの開発プロセスを見直しを行い、ソフトウェア構造と制御対象（プラント）に着目し、シミュレーションを用いるテスト駆動開発を取り入れたプロセス改善方法について提案しています。発表内容はエンジン制御に特化していますが、他の制御機器にも適用できる開発プロセスだと思います。
ダウンロード数： 279回
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手法を選択することを提案している。単に手法ありきで導入するのではなく、本来の目的を把握・意識したうえで、本当に望まれている結果を導くための重要な考え方を提示している。
ダウンロード数： 270回
紹介文 :
「KWS 振り返り」([K]PT+[W]hy なぜなぜ分析+[S]olution 対策）を用いて振り返りをこなった後の『横展開』と『再利用』のため仕組みの構築である。これにより、組織レベルで同類の問題の再発防止に役立つことが判明した。
「KWS 振り返り」([K]PT+[W]hy なぜなぜ分析+[S]olution 対策）を用いて振り返りをこなった後の『横展開』と『再利用』のため仕組みの構築である。これにより、組織レベルで同類の問題の再発防止に役立つことが判明した。
ダウンロード数： 257回
紹介文 :
派生開発時のテストでは、変更の影響範囲を考慮しテスト観点の抜け漏れを抑えるテスト要求分析が重要です。 本論文ではHAYST法の「ラルフチャート」を派生開発の前後で作成し両者を比較することで「変更の影響範囲を考慮したテスト観点を導出する」というテスト分析手法を研究したものです。
派生開発時のテストでは、変更の影響範囲を考慮しテスト観点の抜け漏れを抑えるテスト要求分析が重要です。 本論文ではHAYST法の「ラルフチャート」を派生開発の前後で作成し両者を比較することで「変更の影響範囲を考慮したテスト観点を導出する」というテスト分析手法を研究したものです。
ダウンロード数： 244回
執筆者 :
木本 和伸 （富士通株式会社）
、山中 美穂 （株式会社東芝）
、山口 繁 （日本ユニシス株式会社）
、岡崎 一洋 （サイボウズ株式会社）
、横須賀 信介 （テックスエンジソリューションズ株式会社）
、伊藤 潤平 （ウイングアーク1st株式会社）
紹介文 :
アジャイル開発の品質保証における製品品質を評価プロセスの改善提案である。開発途中にプロセスゲートという評価マイルストンをおいて品質をみえる化し、それを積み上げていくことで、製品品質の品質保証のための評価法を提案している。
アジャイル開発の品質保証における製品品質を評価プロセスの改善提案である。開発途中にプロセスゲートという評価マイルストンをおいて品質をみえる化し、それを積み上げていくことで、製品品質の品質保証のための評価法を提案している。
ダウンロード数： 238回
執筆者 :
川又 悠 （アンリツエンジニアリング株式会社）
、森本 美奈子 （富士ゼロックス株式会社）
、小林 尋文 （ライフマティックス株式会社）
、小関 直子 （サイボウズ株式会社）
、歌田 悠紀 （TIS株式会社）
紹介文 :
アジャイル開発のスクラムフレームワークにおける要求プロセスにおいて、もっとも要求の品質にかかわるアクティビティの一つがリファインメントです。この論文は、要求における問題で手戻りになる問題がリファインメントのやり方にあることを認識し、実用性のある改善の方法を提案している。いままで、リファインメントの課題や改善について議論されている文献はほとんどなく、新規性を持った論文である。
アジャイル開発のスクラムフレームワークにおける要求プロセスにおいて、もっとも要求の品質にかかわるアクティビティの一つがリファインメントです。この論文は、要求における問題で手戻りになる問題がリファインメントのやり方にあることを認識し、実用性のある改善の方法を提案している。いままで、リファインメントの課題や改善について議論されている文献はほとんどなく、新規性を持った論文である。
ダウンロード数： 223回
SQuBOK分類 :
2.2.3 プロセスモデル 、 2.2 ライフサイクルプロセスのマネジメント 、 2.3 ソフトウェアプロセス改善のマネジメント 、 2.12.2 プロセス設計におけるテーラリング 、 2.18 テストのマネジメント
2.2.3 プロセスモデル 、 2.2 ライフサイクルプロセスのマネジメント 、 2.3 ソフトウェアプロセス改善のマネジメント 、 2.12.2 プロセス設計におけるテーラリング 、 2.18 テストのマネジメント
執筆者 :
崔 恩瑛（三星ＳＤＳ）
、木田 昌平（セゾン情報システムズ）
、福留 広晃（オムロンソフトウェア）
、藤村 薫（産能コンサルティング）
、中島 則秋（エス・キュー・シー）
、横田 正樹（パイオニアシステムテクノロジー）
紹介文 :
テストの効率化を目的にSW-CMMに含まれるキープラクティス(KP)を テスト観点で解釈し成熟度レベル順に整理した研究。TPI (Test Process Improvement）を参照し、SW-CMMユーザー組織に分かりやすい連続表現的な整理を目指した。CMMIでの連続表現に比べ幅色い、キープロセスエリア(KPA)からプラクティスが集められており、テスト専門チームでの改善を検討する際に参考になる。
テストの効率化を目的にSW-CMMに含まれるキープラクティス(KP)を テスト観点で解釈し成熟度レベル順に整理した研究。TPI (Test Process Improvement）を参照し、SW-CMMユーザー組織に分かりやすい連続表現的な整理を目指した。CMMIでの連続表現に比べ幅色い、キープロセスエリア(KPA)からプラクティスが集められており、テスト専門チームでの改善を検討する際に参考になる。
ダウンロード数： 215回
紹介文 :
派生開発における開発プロセスとして、XDDPの有効性が多くの現場で示されています。一方で、従来とは違う成果物が必要になるなど、短期間での開発を求められる現場では、導入への抵抗感が強いのも事実です。本発表では、この両者をスムーズにつなぐための具体的な方法を提示しており、XDDPの推進に意欲的なチームの助けになることでしょう。
派生開発における開発プロセスとして、XDDPの有効性が多くの現場で示されています。一方で、従来とは違う成果物が必要になるなど、短期間での開発を求められる現場では、導入への抵抗感が強いのも事実です。本発表では、この両者をスムーズにつなぐための具体的な方法を提示しており、XDDPの推進に意欲的なチームの助けになることでしょう。
ダウンロード数： 203回
執筆者 :
木谷 強（NTTデータ）
、伏田 享平（NTTデータ）
、藤貫 美佐（NTTデータ）
、丹羽 隆（NTTデータ）
、大杉 直樹（NTTデータ）
、新井 広之（NTTデータ）
、戸村 元久（NTTデータ）
、井ノ口 伸人（NTTデータ）
紹介文 :
品質管理においては工数やバグ数等の定量的な数値データであるメトリクスを収集、分析することで定量的な品質管理が可能になりますが、これらのメトリクスを正しく収集するには大きなコストが必要となり、規模の大きくないプロジェクトではメトリクス収集にコストを割けない現状があります。これらを解決するために軽量開発プロセスにおけるTracを用いたチケット駆動開発に基づくメトリクス収集・蓄積・利用する方法を実際に規模の異なる二案件に適用し、案件規模による差やメリット等を紹介している点が分かりやすいです。
品質管理においては工数やバグ数等の定量的な数値データであるメトリクスを収集、分析することで定量的な品質管理が可能になりますが、これらのメトリクスを正しく収集するには大きなコストが必要となり、規模の大きくないプロジェクトではメトリクス収集にコストを割けない現状があります。これらを解決するために軽量開発プロセスにおけるTracを用いたチケット駆動開発に基づくメトリクス収集・蓄積・利用する方法を実際に規模の異なる二案件に適用し、案件規模による差やメリット等を紹介している点が分かりやすいです。
ダウンロード数： 197回
SQuBOK分類 :
1.2 品質のマネジメントの概念 、 2.1 ソフトウェア品質マネジメントシステムの構築と運用 、 2.2.3 プロセスモデル 、 2.3 ソフトウェアプロセス改善のマネジメント
1.2 品質のマネジメントの概念 、 2.1 ソフトウェア品質マネジメントシステムの構築と運用 、 2.2.3 プロセスモデル 、 2.3 ソフトウェアプロセス改善のマネジメント
紹介文 :
ISO9001（2000年版）の認証を取得してる企業がCMM(SW-CMM)の取得を目指すためのガイド。 ISO9001認証後にプロセス改善を行う際にCMMIを参考にする場合にも有効。 ISO9001未取得の企業の場合はIOS9001/CMMの要求から自社の状況で施策のベースを検討するのにも有効である。
ISO9001（2000年版）の認証を取得してる企業がCMM(SW-CMM)の取得を目指すためのガイド。 ISO9001認証後にプロセス改善を行う際にCMMIを参考にする場合にも有効。 ISO9001未取得の企業の場合はIOS9001/CMMの要求から自社の状況で施策のベースを検討するのにも有効である。
ダウンロード数： 170回
執筆者 :
蛸島 昭之（デンソー）
紹介文 :
メカトロニクスの分野では、新規開発の比率が高まりつつあり、不確実性が高いことが問題になっています。 本発表では、反復開発プロセスを適用する際の課題を整理したうえで、スクラムやTDDといったプラクティスの導入、CIの適用など、具体的な解決策を整理しています。ソフトウェアとハードウェアでチームが分かれているという特性から、スクラムを修正して適用しており、導入しやすい形にしているのが特徴です。
メカトロニクスの分野では、新規開発の比率が高まりつつあり、不確実性が高いことが問題になっています。 本発表では、反復開発プロセスを適用する際の課題を整理したうえで、スクラムやTDDといったプラクティスの導入、CIの適用など、具体的な解決策を整理しています。ソフトウェアとハードウェアでチームが分かれているという特性から、スクラムを修正して適用しており、導入しやすい形にしているのが特徴です。
ダウンロード数： 167回
紹介文 :
派生開発では新規開発時の作りの悪さや、その後の派生開発での変更作業によってソースコードの劣化が進んでいることが多く、変更ミスを引き起こす要因になっている。ソースコードの劣化を改善する方法としてリファクタリングがあるが、仕様の変更作業の中で、”良かれ“と思って、担当者の判断で安易に構造を変えてしまったり、無造作にリファクタリングにとりかかったりすることでかえって事態を悪化させることが多い。 XDDPでは、仕様変更の中でソースコードの劣化を和らげるために、当該関数に限定した「小さなリファクタリング」を許しているが、これだけでは足りない。 そこで、XDDPを応用してリファクタリングに特化した派生開発プロセスとして「R-XDDP」という方法を提案し、リファクタリング・パターンを限定しながら、混乱することなくリファクタリングに取り掛かる方法を勧めている。
派生開発では新規開発時の作りの悪さや、その後の派生開発での変更作業によってソースコードの劣化が進んでいることが多く、変更ミスを引き起こす要因になっている。ソースコードの劣化を改善する方法としてリファクタリングがあるが、仕様の変更作業の中で、”良かれ“と思って、担当者の判断で安易に構造を変えてしまったり、無造作にリファクタリングにとりかかったりすることでかえって事態を悪化させることが多い。 XDDPでは、仕様変更の中でソースコードの劣化を和らげるために、当該関数に限定した「小さなリファクタリング」を許しているが、これだけでは足りない。 そこで、XDDPを応用してリファクタリングに特化した派生開発プロセスとして「R-XDDP」という方法を提案し、リファクタリング・パターンを限定しながら、混乱することなくリファクタリングに取り掛かる方法を勧めている。
ダウンロード数： 165回
SQuBOK分類 :
1.2 品質のマネジメントの概念 、 2.1 ソフトウェア品質マネジメントシステムの構築と運用 、 2.2.3 プロセスモデル 、 2.3 ソフトウェアプロセス改善のマネジメント
1.2 品質のマネジメントの概念 、 2.1 ソフトウェア品質マネジメントシステムの構築と運用 、 2.2.3 プロセスモデル 、 2.3 ソフトウェアプロセス改善のマネジメント
紹介文 :
品質の向上とは、究極的には顧客満足度の向上であり、そのためには、組織全体を、顧客に対する新しい価値を創造し、積極的に提案する顧客価値経営に到達させることが必要である。本論文は、「日本経営品質賞」のフレームワークをベースに、顧客価値経営到達への道筋を、具体的改善項目の実施度合により示しており、アセスメントと改善の繰り返しにより組織レベルを向上させることができる点が、有益かつ実践的である。
品質の向上とは、究極的には顧客満足度の向上であり、そのためには、組織全体を、顧客に対する新しい価値を創造し、積極的に提案する顧客価値経営に到達させることが必要である。本論文は、「日本経営品質賞」のフレームワークをベースに、顧客価値経営到達への道筋を、具体的改善項目の実施度合により示しており、アセスメントと改善の繰り返しにより組織レベルを向上させることができる点が、有益かつ実践的である。
ダウンロード数： 158回
紹介文 :
１つの変更要求が及ぼす影響というのは時として他システムに跨ることもあります。この影響範囲を特定する方法として派生開発で使用されるXDDPを採用しました。 変更依頼を要求と仕様の階層構造で表現し、要求レベルで他システムへの影響を検討することで影響範囲を特定しようとした試みです。
１つの変更要求が及ぼす影響というのは時として他システムに跨ることもあります。この影響範囲を特定する方法として派生開発で使用されるXDDPを採用しました。 変更依頼を要求と仕様の階層構造で表現し、要求レベルで他システムへの影響を検討することで影響範囲を特定しようとした試みです。
ダウンロード数： 157回
SQuBOK分類 :
1.2 品質のマネジメントの概念 、 2.1 ソフトウェア品質マネジメントシステムの構築と運用 、 2.2.3 プロセスモデル 、 2.3 ソフトウェアプロセス改善のマネジメント
1.2 品質のマネジメントの概念 、 2.1 ソフトウェア品質マネジメントシステムの構築と運用 、 2.2.3 プロセスモデル 、 2.3 ソフトウェアプロセス改善のマネジメント
執筆者 :
野村 尚幸（富士通関西中部ネットテック）
、藤田 英雄（富士通西日本コミュニケーション・システムズ）
、天田 正敏（横河電機）
、中瀬 泰恵（ＮＴＴソフトウェア）
、丹羽 武志（インテック）
、石田 芳昭（野村総合研究所）
、正木 京一（オージス総研）
、小代 泰彰（インテック）
、佐藤 育夫（ＮＴＴコムウェア）
、沖田 健治（ユーフィット）
紹介文 :
ISO9001（2000年版）の認証を取得してる企業がCMMを参考にしてさらに改善をしていくためのガイド ISO9001未取得の企業の場合はIOS9001/CMMの要求から自社の状況で施策のベースを検討するのにも有効である。
ISO9001（2000年版）の認証を取得してる企業がCMMを参考にしてさらに改善をしていくためのガイド ISO9001未取得の企業の場合はIOS9001/CMMの要求から自社の状況で施策のベースを検討するのにも有効である。
ダウンロード数： 157回
執筆者 :
林 勝義 （パイオニア）
、美濃島 和智（アンリツエンジニアリング）
、前田 直毅（インテック）
、細田 孝（キヤノン）
、遠藤 剛一（アドバンテスト）
、羽田 義秋（日立システムアンドサービス）
紹介文 :
CMMからCMMIへのスムーズな移行を目的として、両モデルの比較考察を行い、両モデルのゴールとプラクティスの対応関係と見解をまとめたマッピング表を作成しています。 また、CMMからCMMIへの移行の際に優れていると思われる点5つ（要件管理、リスク管理、計測と分析、エンジニアリング、決定分析と解決）につて整理されています。
CMMからCMMIへのスムーズな移行を目的として、両モデルの比較考察を行い、両モデルのゴールとプラクティスの対応関係と見解をまとめたマッピング表を作成しています。 また、CMMからCMMIへの移行の際に優れていると思われる点5つ（要件管理、リスク管理、計測と分析、エンジニアリング、決定分析と解決）につて整理されています。
