ここに載っていることは基本中の基本です、さらに詳しいことは書籍やサイトを回って調べてください。
まず、プログラムを使って何をしたいのかを、箇条書きにしておきましょう。今まで何度もやってきたように、優先順をつけ取捨選択をして、組み合わせておきます。大きなシステムの場合は、概念図を作ってシステムの流れを簡単に把握できるようにしておきましょう。
実際にどんな機能にするかを決めて、どのような開発環境や実装環境にするかも決めます。システム全体の概念図等も作成します。
プログラム全体の流れをデザインします。概念図から構造図を作成します。つまり実際の環境を想定して全体の構造を作ります。そして、各モジュールごとにもフローチャートで流れ図を作っておくといいでしょう。
プログラムの中で利用されるデータの管理は、大規模になればなるほど正確に記述し間違って使用したりしないように心がける必要があります。管理法については様々な手法があり、データからプログラム設計を始める方法もあるほど多様にあります。ここでは詳しい説明は出来ませんが、ぜひ勉強しておいてください。
商品管理などのデータが重要な位置を占めるなプログラムは、データベースの設計が必要です。中規模以上のWebサイトでは、一般的にデータベースが良く利用されています。
実際にプログラムの入力作業に入ります。設計図が出来ているとこの入力作業は非常にスムーズなものになります。
普通、プログラムのスタイルは人それぞれみんな個性的で、基本的には自由にやっていいものです。ですが、共同作業をしている場合や、後の変更にためには、一定のルールに則った作業が必要です。まず、重要なコードには必ず「コメント」をつけましょう。つけないで長いプログラムを作った場合、コードを読んでも何をやっていたのか分からなくなる場合があります。
古典的な方法ですが、フローチャートを必ず作っておくことも重要です。ただのコードの状態では見つからなかった欠陥や改良点が簡単に把握できます。設計の時点で作っておけばいいのですが、一般的に余り使われていないようです。自分で把握できる範囲を超えたと思いはじめてからでも遅くないので、ぜひ作っておきましょう。言語によっては、構造を分かりやすい形で出力してくれるソフトもあるので活用してみましょう。
プログラムが設計通り動いているかチェックするのが、「デバッグ」という作業です。この作業のほうが、プログラミングの3倍以上の時間がかかることは良くあることです。まずは、必要な機能が満たされているかチェックして、次は不正な入力に対応できているかを調べます。いくらソフトが完璧でも、操作するのは人間なので何をするか分かりません。丁寧にチェックしてトラブルを未然に防ぎましょう。
サイトの規模によってはαテスト(開発者やチーム内での公開テスト)やβテスト(特定のユーザーにモニターになってテストしてもらう)も行います。
テストが終われば、システムは完成です。しかし、必ずまだバグは潜んでいます。忘れずに覚えておきましょう。