組み込みソフト開発をしていると、V字モデルに違和感を感じる場面はないでしょうか。
大きめの会社だと、会社の方針でV字モデルを採用しているところが多いですよね。でも本当に納得していますか？
確かにV字モデルはわかりやすいです。
１．要件定義 ⇔ ６．受入テスト
２．基本設計 ⇔ ５．結合テスト
３．詳細設計 ⇔ ４．単体テスト
１から６の順に開発を進めていけば開発工程とテスト工程が紐づいて品質が担保できます。理想としては正しいです。
ただ、実際の組み込みソフト開発の現場では、V字通りに進むことはほとんどありません。
例えば、次のような状況が日常的に起きます
・開発前に仕様が決まっていない
・設計や実装の時点で問題が見つかる
・開発終盤で新たな要件が追加になる
この違和感の正体を少し分解してみると、次のように整理できます。
・V字という手順で固定されている
・予定通りに進まないということが前提になっていない
・組み込み開発はハード要因でトラブることがある
それでもなぜV字モデルが使われ続けるのでしょうか？
・ハード設計や品質評価の予定が組みやすい（ハード、品質部門）
・進捗や期日の管理がやりやすい（マネージメント部門）
・進捗度合いを報告しやすい（課長、部長、社長への報告）
ソフト開発者の現場感覚とは少しズレたところで設計されているとも言えます。
では、この違和感とどう向き合えばいいのでしょうか。
・スケジュールに何とか間に合わせるため、できる人に何とかしてもらう（属人化）
・上流工程が不完全なまま進めた結果、あとで手戻りが大量に発生する
・開発要件をすべて処理しきれず、スケジュールが破綻する
ではどうしたらいいのか？
V字モデルは否定すべきものではありませんが、そのまま現場に当てはめると違和感が生まれます。
組み込みソフト開発の現場では上流から下流へ一方向で流れるものではなく、行き来する前提で考えた方が実態に近いと感じています。
このあたりの考え方や、具体的にどう扱うかについては、別の記事で整理してみたいと思います。
組み込みエンジニアとして30年以上、C/C++やLinuxを中心に開発しています。
現場でのトラブル対応や設計判断の経験をもとに、実務で詰まりやすいポイントを中心に発信しています。
同じように現場で詰まっている方の参考になればと思っています。
プロフィールはこちら
→ プロフィールページ
コメント