対象読者
- ウォーターフォール開発者の方
- SIerの方
結論
ソフトウェア開発の伝統的な手法「ウォーターフォール開発」。伝統故に当然正しい手法だと多くの現場で信じられている。天動説のように。
しかし、今やウォーターフォール開発は完全に間違っていることが分かった[1]。
本記事では、ウォーターフォール開発の中でも、実際に作る工程にフォーカスし、それが間違っていることを示す。
基本設計(I/O 要件の機能分割)
↓
詳細設計(機能をソフトウェア部品の組み合わせとして表現)
↓
実装(詳細設計で考えたソフトウェア部品を作成)
機能分割という表現の誤り
機能の分解方法と一口に言っても様々なやり方がある
オブジェクト指向
関数プログラミング
要件さえ満たされていれば良い。保守性への関心が薄いウォーターフォール
人月として実装部隊の生産性を数える、という誤り
設計は実装のフィードバックを通して改善するもの
作ってみてはじめて、もっと良い表現が見つかる
事前に最善を見つけ出すのは不可能
最善とは、その時の状況に依存しており、実装が進んだり、保守段階に入ったとき、それは最善ではなくなっている。
詳細設計書の役割
詳細設計は実際にプログラミングを行う工程(実装)の手順を計画する作業だ。
ウォーターフォール開発では、要件を実現するためのシステムを機能ごとに分割し、それらを組み合わせて要件を実現することを考える。
複雑なシステムを機能分割によって理解可能にし、かつその実装作業を分担できるようにしてくれる。
これが基本設計である。
それらの機能をさらにソフトウェアの部品単位に分割し、再構成する方法を考えるが詳細設計である。
ハードウェアにおける設計書は解釈が一意であり、誰が見ても同じ製造物を作ることが可能なほど具体的である。なぜなら、ハードウェアは三次元的な実体を持つため、その設計書は図面として表現できるからだ。1メートルや30°と書いてあれば、他に解釈の余地はない。
ソフトウェアの設計とはドキュメントではなく、ソースコードだ
要件定義の次は設計フェーズだ。しかし、ウォーターフォール開発における設計(以後、ウォーターフォール設計と書く)もイケていない。
ハードウェアの設計は図面として表され、万人に対して解釈が一意である。文章とは違って、数値は誰から見ても同じものである。図面には数値が多用されているため、解釈が一意なのだ。
対して、ウォーターフォール設計は曖昧だ。なぜなら、それは文章や図表(フローチャートなど、図面ほど具体的ではない)によってソフトウェアを表現したものに過ぎず、その”実装”方法には色んなやり方があり得るからだ。
ここでサラッと”実装”と述べた。ウォーターフォール設計では実装のことを製造やコーディングとも呼ぶ。つまり、製造業での製品はウォーターフォール開発でのソースコードに対応する。この捉え方は誤りだ。
製造業では設計に則りさえすれば、ちゃんと製品を作ることができるのは上述の通りだ。しかし、ウォーターフォール設計に従っても、しっかりした製品(ソースコード)が作られる保証はない。そういう意味で、ウォーターフォール設計は製造業における設計の役割を全うできない。
もし、ハードウェア設計と同等のものがソフトウェアにあるのなら、それはソースコードに他ならない。ソースコードは解釈が一意であり、それに則って実行ファイルが生成されるからだ。製造業の製品に対応するのは実行ファイルであり、設計に対応するのはソースコードなのだ。
コメント