少なくとも個人的な経験からではありますが、最近のソフトウェア開発は、殆どが短期の派生開発。
そのため、ステークスホルダー要求獲得(関係者要求獲得)→関係者要求分析→システム要件抽出→アーキテクチャ設計(静的構造と動的振る舞いとI/Fの定義)が、省略されることが多いように思います。
また、構成管理の仕組みが弱いと、派生開発を繰り返すと、要求分析資料、設計資料やソースコード、テストケースなどの開発資産間のトレーサビリティが切れていきますが、構成管理などの支援活動に頓着しない方も多いようです。
本当に必要ないなら、これらの活動を省略してももちろん品質に影響がありません。
しかし後々問題を起こすソフトウェア開発組織は、これらの活動をそもそも知らなかったり、顧客や品質保証組織から、言われたらとりあえずやりました的な事が多いように思います。
必要な品質活動の全体が見える化され、その中から、関係者要求に合わせて、活動を強化したり、省略できれば、安全に効率よく開発できます。
そのために、分析できて、全体像を描ける、テスト技術者や品質技術者が増えたら良いと思いました。
そのため、ステークスホルダー要求獲得(関係者要求獲得)→関係者要求分析→システム要件抽出→アーキテクチャ設計(静的構造と動的振る舞いとI/Fの定義)が、省略されることが多いように思います。
また、構成管理の仕組みが弱いと、派生開発を繰り返すと、要求分析資料、設計資料やソースコード、テストケースなどの開発資産間のトレーサビリティが切れていきますが、構成管理などの支援活動に頓着しない方も多いようです。
本当に必要ないなら、これらの活動を省略してももちろん品質に影響がありません。
しかし後々問題を起こすソフトウェア開発組織は、これらの活動をそもそも知らなかったり、顧客や品質保証組織から、言われたらとりあえずやりました的な事が多いように思います。
必要な品質活動の全体が見える化され、その中から、関係者要求に合わせて、活動を強化したり、省略できれば、安全に効率よく開発できます。
そのために、分析できて、全体像を描ける、テスト技術者や品質技術者が増えたら良いと思いました。
※コメント投稿者のブログIDはブログ作成者のみに通知されます