ウォーターフォール方式開発とプログラミング
ウォーターフォールモデルの図。上流から下流に流れる水のようになるため、この名がついた。
中山テックはChatGPTで補完しきれない
「視覚」(画像)を取り入れ
「参考になった!」と思っていただける
ブログ執筆を目指してます

中山テック 代表の中山です。

本日もプログラミングに関するブログ(開発者向け)となりますが

ウォーターフォール方式におけるプログラミングの扱いをお話させていただきます。

アーキテクチャ(環境構造)が決まっていたら早速開発の開始となります。

その歳に下記のような流れで開発が行われます。

ウォーターフォールモデルの図。上流から下流に流れる水のようになるため、この名がついた。

⬛️要件定義→お客さんの要望をまとめたもの

⬛️基本設計→全体的な処理の流れやサーバー同士のIF仕様、DB設計など

⬛️詳細設計→プログラムの影響範囲・処理の流れやSQLなどここで定義します

そのあとにプログラミングとなります。

  • 関連記事

ウォーターフォールとプログラミング

各設計書がどんなことをするのかわかったところで、勘のいい方はお気付きかもしれませんが

詳細設計書があるのでウェイトはそんなに大きくありません。

逆に詳細設計見ながらやるので、トレースしているようなものなのです。

もちろんトレースできる能力が求められますが・・・

また締め切りがタイトだと「設計書フェーズで時間を取りすぎたので

プログラミングの工数を極力減らす」というのも現実なのです。

ウォーターフォール方式におけるテストフェーズ

プログラミング以降は品質担保のためのテストフェーズになります。

各テストは、設計書と結び付いておりこれもいくらかのフェーズでわかれています。

ちなみに、開発よりもテストフェーズの方が長く、単調なテストの繰り返しで飽きてしまい

「想像してたのと違った」と思う方がほとんどです。

まとめ

いかがでしたでしょうか。

プログラミングを習得するのも重要ですが、質の良い設計書作成・テスト仕様書・

テスト実施がウェイトを占めます。

ただレベルの高い現場のプログラミングをしたいのなら

このような下積みを経て習得しないと難しいのも現実です。

初心者中堅業種問わず、質の高い作業を行うことを忘れずに邁進することが一番ですね(自分も含め)。

※中山テックに掲載しているゲーム画像の著作権、商標権、その他知的財産権は、当該コンテンツの提供元に帰属します


おすすめの記事