顧客との合意後の仕様齟齬検出意義とメトリクスについて
~仕様齟齬の予兆検出および最適な対処方法選択の提案~
ダウンロード数: 168回
SQuBOK分類 :
2.2.3.1 ウォーターフォールモデル 、 2.2.3.3 プロトタイピング 、 2.2.3.5 アジャイル開発 、 2.12 プロジェクトマネジメント 、 3.1 メトリクス
2.2.3.1 ウォーターフォールモデル 、 2.2.3.3 プロトタイピング 、 2.2.3.5 アジャイル開発 、 2.12 プロジェクトマネジメント 、 3.1 メトリクス
発表場所 : SQiP研究会
主査 : 三浦 邦彦(矢崎総業株式会社)
副主査 : 中森 博晃(パナソニック ファクトリーソリューションズ株式会社) 、山田 淳(東芝ソフトウェア・コンサルティング株式会社)
執筆者 : 市川 孝裕(株式会社インテリジェンス ビジネスソリューションズ) 、海野 和由(矢崎総業株式会社) 、小林 道央(株式会社インテック) 、山本 久代(サントリーシステムテクノロジー株式会社)
副主査 : 中森 博晃(パナソニック ファクトリーソリューションズ株式会社) 、山田 淳(東芝ソフトウェア・コンサルティング株式会社)
執筆者 : 市川 孝裕(株式会社インテリジェンス ビジネスソリューションズ) 、海野 和由(矢崎総業株式会社) 、小林 道央(株式会社インテック) 、山本 久代(サントリーシステムテクノロジー株式会社)
紹介文 :
自社内での改善を進めていくと、開発現場での最終的な改善の目標は、いかに顧客の要求を早い段階で適切に引出して共有できるか、即ち“要求仕様の早期明確化”となる。然しながら、プロジェクトが進み仕様が詳細化されるに連れて、仕様齟齬が発生するケースが数多くみられる。アジャイル手法による反復開発の導入は解決策の一つだが、ウォーターフォール開発で経験を積んできたプロジェクトチーム全体がすぐに導入するのは難しい。そこで開発中に、仕様齟齬が大きくなり始めた開発対象機能の発生を把握して抽出し、そのような機能に限定して、テストシナリオの先行作成、プロトタイプ開発や先行開発など、部分的な反復開発を導入して対処する手段を提案している。
このため本研究では、仕様齟齬の予兆を、顧客と開発チームの特徴に関する「開発の特性」と仕様変更に関する「メトリクス」をモニタリングして察知し、「対処パターンと判断基準」を活用してプロジェクト進行中に部分的に開発プロセスを変更させていく、仕様齟齬の早期解決手段を提案し体系化した。
顧客との仕様整合の完成度は、その後のプロジェクト進捗に大きな影響を与えるが、本テーマは、“要求仕様の早期明確化”を支援する有用な一方策を提供する。
自社内での改善を進めていくと、開発現場での最終的な改善の目標は、いかに顧客の要求を早い段階で適切に引出して共有できるか、即ち“要求仕様の早期明確化”となる。然しながら、プロジェクトが進み仕様が詳細化されるに連れて、仕様齟齬が発生するケースが数多くみられる。アジャイル手法による反復開発の導入は解決策の一つだが、ウォーターフォール開発で経験を積んできたプロジェクトチーム全体がすぐに導入するのは難しい。そこで開発中に、仕様齟齬が大きくなり始めた開発対象機能の発生を把握して抽出し、そのような機能に限定して、テストシナリオの先行作成、プロトタイプ開発や先行開発など、部分的な反復開発を導入して対処する手段を提案している。
このため本研究では、仕様齟齬の予兆を、顧客と開発チームの特徴に関する「開発の特性」と仕様変更に関する「メトリクス」をモニタリングして察知し、「対処パターンと判断基準」を活用してプロジェクト進行中に部分的に開発プロセスを変更させていく、仕様齟齬の早期解決手段を提案し体系化した。
顧客との仕様整合の完成度は、その後のプロジェクト進捗に大きな影響を与えるが、本テーマは、“要求仕様の早期明確化”を支援する有用な一方策を提供する。
概要 :
ソフトウェア品質は上流工程で担保することが大前提である.しかしながら,ウォーターフォール型の開発プロセスにおいて,上流工程で顧客と十分に仕様を整合したはずであるにも関わらず,開発工程が完了し,受入れ検査を実施した際に,顧客と開発チームでの仕様の解釈違い(仕様齟齬)が発覚するケースがある.そこで我々は,然るべき「開発の特性」と「メトリクス」を定義し,モニタリングを実施すれば,開発の途中で仕様齟齬の予兆を検知できるのではないか,また,予兆を検知した後,プロジェクトが狙う品質(Quality)・コスト(Cost)・納期(Delivery),および開発チームの変化への適応能力に応じて,どのように対処すべきかを定義した「対処パターンと判断基準」を準備しておくことにより,最適な対処方法を合理的に選択できるのではないかという二つの仮説を立てた.
仮説を検証するため,研究員の所属各社のソフトウェア開発関係者を対象にアンケート調査を実施し,本研究で定義した「開発の特性」,「メトリクス」の有効性と実現性を確認した.また,「対処パターンと判断基準」の有効性を確認し,条件が整えば実現性がある事を確認した.
ソフトウェア品質は上流工程で担保することが大前提である.しかしながら,ウォーターフォール型の開発プロセスにおいて,上流工程で顧客と十分に仕様を整合したはずであるにも関わらず,開発工程が完了し,受入れ検査を実施した際に,顧客と開発チームでの仕様の解釈違い(仕様齟齬)が発覚するケースがある.そこで我々は,然るべき「開発の特性」と「メトリクス」を定義し,モニタリングを実施すれば,開発の途中で仕様齟齬の予兆を検知できるのではないか,また,予兆を検知した後,プロジェクトが狙う品質(Quality)・コスト(Cost)・納期(Delivery),および開発チームの変化への適応能力に応じて,どのように対処すべきかを定義した「対処パターンと判断基準」を準備しておくことにより,最適な対処方法を合理的に選択できるのではないかという二つの仮説を立てた.
仮説を検証するため,研究員の所属各社のソフトウェア開発関係者を対象にアンケート調査を実施し,本研究で定義した「開発の特性」,「メトリクス」の有効性と実現性を確認した.また,「対処パターンと判断基準」の有効性を確認し,条件が整えば実現性がある事を確認した.