SE基本情報に出るIT用語

ウォーターフォールモデルとは?システム開発の工程を順番通りに進めること

ウォーターフォールモデルとは、システム開発の工程を順番通りに進めていくことです。

ウォーターフォールモデル

システム開発の各工程をそれぞれざっとわかりやすく書くと、下記の通り。

システム開発の工程
  • 要件定義(どんなシステムを作るか、決めること。「ドラクエを作るのか?FFを作るのか?」みたいな、「そもそも論」)
  • 基本設計(見た目の部分、ざっくりのストーリーを決める。)
  • 詳細設計(そのストーリーは、プログラムでどうやって実現するのかを書く)
  • プログラミング(ソースコードを書いて、プログラム(製品)にする
  • 単体テスト(1つのプログラムを単体で動かすんだな~くらいでOK)
  • 結合テスト(複数のプログラムを合体させるテストがあるんだな~でOK)
  • 総合テスト(使い物になるかを確認して仕上げるんだな~でOK)
  • 運用・保守(ドラクエを発売した後に、バグがあったら直さないかん)

1つの工程をガチガチに固めて完了させたあとに、次の工程を順番に進めます。

「今、何をやっているのか?」がはっきりして、進捗状況がわかりやすい(管理しやすい)ので、大規模なシステム開発でよく使われます。

ただ、順番通りにやる分、手戻り(やりなおし)が発生するとダメージが大きくなるのが難点。

戻る工程が多いほど、やり直す工程とコストも多くなるといったイメージです(*´ω`)。

スポンサーリンク

ウォーターフォールモデルでは各工程を順番に進める

waterfallは、「滝」の意味。

ウォーターフォールモデルでは、「滝が流れ落ちるイメージ」のように、各工程を順番に進めていきます。

システム開発の工程

システム開発の工程は、冒頭でも書いた通りです。

システム開発の工程
  • 要件定義(どんなシステムを作るか、決めること。「ドラクエを作るのか?FFを作るのか?」みたいな、「そもそも論」)
  • 基本設計(見た目の部分、ざっくりのストーリーを決める。)
  • 詳細設計(そのストーリーは、プログラムでどうやって実現するのかを書く)
  • プログラミング(ソースコードを書いて、プログラム(製品)にする
  • 単体テスト(1つのプログラムを単体で動かすんだな~くらいでOK)
  • 結合テスト(複数のプログラムを合体させるテストがあるんだな~でOK)
  • 総合テスト(使い物になるかを確認して仕上げるんだな~でOK)
  • 運用・保守(ドラクエを発売した後に、バグがあったら直さないかん)

それぞれの工程をカンペキに仕上げる

「何を作るか?」を決める要件定義では、何を作るかをカンペキに決めます

■要件定義のイメージ

要件定義とは

「とりあえず、作ってみますね」みたいなことはしないのが特徴(逆に、ある程度あいまいでも作ってしまうのが「アジャイル開発」)。

要件定義で決めたことをもとに、設計(どんなプログラムにするかを決める工程)に入って。

そこでも、「どんなプログラムにするか?」をカンペキに設計します。

■設計のイメージ

内部設計はプログラムの流れ

「プログラムのイメージが固まってないけど、とりあえずコーディングします!」みたいなことはしないのが特徴(逆に、それでもプログラムを書くのが「アジャイル開発」)。

設計をもとに、やはりプログラミングでカンペキに動くものを作りつつ。

最後に、作ったものが動くかを確認する単体テスト・結合テスト・総合テストへと進めて完成させます。

■テストの一例

ホワイトボックステストの条件網羅

手戻りは発生しない前提

「何回、『カンペキに』と書くんだよ!」と思ったかもですが。

ウォーターフォールモデルでは、滝が上に逆流することがないのと同様、手戻りは発生しない前提です。

それぞれの工程で、問題なんてものは発生しない(白い目)ので、手戻りが起こらない前提です。

※反対に、手戻りが発生する前提の開発モデルは、アジャイルって言ったりする。

スポンサーリンク

ウォーターフォールモデルは大規模なシステム開発に使われる

ウォーターフォールモデルは、大規模なシステム開発に使われることが多いです。

ウォーターフォールモデルのメリット

というのも、お堅い企業ほど好みそうなメリットがあるから。

ウォーターフォールモデルのメリット
  • 順番に進めていくので、開発工程のスケジュールを組みやすい
  • 順番に進めていくので、「どの工程がどの程度進んでいるのか?」という進捗が見えやすい
  • スケジュールと進捗のメリットから、規模が大きくゴールが長い開発に向く

システムの全体像が大きいときによく使われるし、お客様も安心できる

銀行のATMや、業務支援システム(例えば、伝票登録したら在庫の管理も請求書の発行もしてくれる)だと、全体像がバカでかいです。

システムの全体像が大きい場合は、それだけ開発期間も長くなるので。

「どれくらいかかるのか?」を、先に見積もっておくほうが、手を付けやすいといえます。

ついでに言うと、ウォーターフォールモデルは「時代遅れ」とディスられたりするのですが、「今、設計が50%進んでいます!」みたいに、進捗の管理や報告もしやすいので。

全体像が大きいシステムを発注しているお客様からしてみれば、かなりの額のお金を出しているので、ウォーターフォールモデルでやってくれたほうが安心感があるしわかりやすいのです。

※大規模になればなるほど、ウォーターフォールを工夫した「スパイラルモデル」(規模が大きいから何回かに分ける考え)が採用されやすいので、ついでに覚えるとよき!

ウォーターフォールモデルのデメリットは手戻りのコストが大きい

ただ、ウォーターフォールモデルにも、手戻りのコストが大きいというデメリットがあります。

「思ってたのと違う」となると、影響が出る分だけやり直し

例えば、コーディングも終えて、作ったものをテストしているときに、「思ってたのと違う」となると、影響が出る分だけやり直しになります。

簡単なもの(ささいなミス)であれば、やり直しといっても、大したことにはならないのですが。

それが、

  • 「他の機能も直さないといけない」(③)
  • 「もう一度プログラムの処理を考えなさないといけない」(②)
  • 「お客様に聞かないといけない」(①)

みたいになってくると、その分だけコスト(時間)がかかります

戻る工程が多いほど修正コストは大きい

言ってしまえば、戻る工程が多いほど、やり直す工程とコストも多くなります。

プログラミングに戻る(③)よりも、設計をやり直す(②)方が、修正コストは大きく。

設計をやり直す(②)よりも、要件定義をやり直す(①)方が、修正コストは大きいです。

ここまで、読んでくれたうえで、冒頭の図をもう一度、見ると理解しやすいかもです(*´ω`)。

ウォーターフォールモデル

【余談】わりとうまくいかないことも多い

ただ、なんとなく察しているかもしれませんが、わりとうまくいかないことも多いです(*´ω`)。

というのも、カンペキである前提で次の工程に進むということは、やり直しがききません。

エンジニア全員が、100%の仕事ができるほど優秀であればいいのですが、そうは問屋が卸さない。

実際には、ミスや抜け漏れ(それもわりと致命的)があったりするのが普通(ましてや、複数人でやっていれば、コミュニケーションのミスだってあるし、常に100%のものができたら苦労しない)。

それに、お客様も途中で「やっぱり、こうしてほしい!」みたいに言ったりする(仕様変更、通称「仕変」)ので、100%の仕事ができていたとしても、その一言で木っ端みじんにされます。

ただ、ひよこSEの個人的な意見としては、ウォーターフォールモデルが悪いわけではないし、お客様が「やっぱり変えたい」と言うのも、高いお金出してるし普通だと思っています。

問題なのは、手戻りが発生することを少しも考えずに、理想論のまま突き進むこと。

むしろ、ウォーターフォールモデルの考え方自体は、理にかなっていると考えているくらい!

反対に言えば、ウォーターフォールモデルであっても、「修正が絶対に発生してはいけない」というルールがあるわけでもないので、修正が発生したらスケジュールを考え直すだけで解決したりするのですが(実際にはそんな余裕がないから、この発言も理想論なんだけどね)。

まぁ、大人の事情としてこの辺にしておきます(*´ω`)。

まとめ

ウォーターフォールモデルときたら、システム開発の工程を順番通りに進めていくことです。

スケジュールも作りやすいし、進捗の管理もしやすいので、なんだかんだよく使われる開発モデル。

順番に進めていく分だけ、手戻り(やりなおし)が大きいとダメージが大きくなるので、そこのコントロールをどうするかが重要なんだなぁ~くらいに思ってくださいまし(-_-;)。

▼この記事がいいと思ったら、下の画像をクリックしてくれたら励みになります!

にほんブログ村 IT技術ブログ システムエンジニアへ
スポンサーリンク
ひよこSEのつぶやきブログ

コメント

タイトルとURLをコピーしました