１：内部設計
「内部設計の内容」
①物理データ設計：外部設計（論理データ設計）の結果を元に、ファイル編成ほうやレコード形式などの設計を行う。さらに、具体的なハードウェア性能をもとにして、アクセス時間の見積もりも行う。
②入手力詳細設計：外部設計（入手力設計）の結果をもとに、具体的な入出力方法（テキストフィールドかドロップダウンメニューかなど）を決めたり、１行の文字数を考慮して出力結果の表示を決めたりする。
２：プログラム設計
内部設計で定義したプログラムをモジュール（プログラムを構成する部品となるもの。モジュールごとに役割（機能）を持つ。サブルーチンや関数をモジュールと考えても良い。）単位に分割します。
モジュールとは、プログラムを組み立てる部品となるソフトウェアです。例えば、
・データを整列するモジュール。
・データベースへの接続を行うモジュール。
・データを表形式にレイアウト（整形）するモジュール。など、汎用的に何にでも利用できる形態にしてあるソフトウェアがモジュールです。
プログラム設計を作っていけば良いのかや、どのようなモジュールを新たに作れば良いのかを決めます。また、モジュール間の関係をわかりやすくまとめるために、モジュール階層図を作ります。設計結果は「プログラム仕様書」にまとめ、文書化します。
３：プログラミング
プログラム仕様書に基づいて、モジュールのコーディングを行っていきます。出来上がったコードが成果物です。
４：テスト
システムが要求仕様通りに機能するかを検査します。
単体テスト、統合テスト（結合テスト）、システムテスト、妥当性確認テスト（運用テスト）
①単体テスト：モジュール他何が正常に動作するかをチェックします。
②統合テスト（結合テスト）：モジュールを組み合わせたときに、正しく連携して動作するかをチェックします。
③システムテスト：基本計画で定めた要求仕様を満たしているかをチェックします。
④妥当性確認テスト（運用テスト）：ユーザ自らが実査の環境下でシステムを使うテストで、いわゆる試運転です。
５：運用・保守
システムは下記のように分類されます。
「システムの保守作業」
①修正保守：バグ（設計上の誤り）を取り除く作業を行う。
②変更（適応）保守：外部環境の変化を反映させる作業を行う。例えば、税率や基準・規格の変化に合わせてシステムを修正する。
③改良保守：ユーザからの改良要求、機能追加要求に対応する作業を行う。
６：レビュー
レビューとは、見直し作業のことです。ウォータフォールモデルでは、工程の後戻りを考慮していませんから、各工は完璧に遂行される必要があります。見落としや誤解などのエラー（誤り）がないかを、成果物（設計文書）を見直して検証します。
レビューには次の技法があります。
「レビューの技法」
①ウォークスルー：開発メンバーで行われるレビュー。担当者自らが成果物の内容を説明して意見を求める。
②インスペクション：進行役であるモデレータによって進められる。ウォークスルーよりも形式的に行う。
③ラウンドロビン：参加者が持ち回りでレビュー責任者を務める。
レビューを行う際には、
・あらかじめ資料を用意し、参加者に配布しておく。
・１〜２時間程度の短時間で行う。
・エラーの発見に専念し、批判、責任追及はしない。
・人的評価を持ち込まない。
という点に注意する必要があります。
※試験例：ウォークスルーは「設計上の誤りを早期に発見することを目的として、作成者と複数の関係者が設計書をレビューする方法」
６：スパイラルモデル
ユーザの要求は代わりやすものです。具体像が見えてくると、
「こんなはずでなかった」
「勘違いだった」
「業務手順が変わったから、それに合わせて欲しい」
など、さまざまな要求の変化が現れます。これらを的確に反映させ長亜システムの開発を行わないと、ユーザが満足するシステムは作れません。したがって、システム開発においては、ユーザの要求を適宜反映させて、軌道修正することが考慮されていなければなりません。
しかし、ウォータフォールモデルでは工程が後戻りすることは考慮していませんから、後から出てきた要求を反映させる手順が考えられていません。無理に反映させようとすると大きなコスト（手間、金銭、時間）がかかるのです。
そこで、後から出てきた要求を反映させやすい開発モデルが考えられました。スパイラルモデルです。スパイラルモデルでは開発工程を何回か繰り返してシステム開発を進めます。ただし何回繰り返すのかを決めておかないと、次から次へと新しい要求が出てきて収拾がつかないことも考えられます。この意味では、いつ開発が終わるのかが不明で、コストや開発期間の見積もりが困難になりがちです。
ベームが提唱したスパイラルモデルでは、
「１」目標、代替案、制約の決定：目標や予算、代替案、制約などを決定する。
「２」代替案とリスクの評価：リスクが最小となる代替案を選び、プロトタイプを作る。
「３」開発とテスト：要求分析や設計、テストを行う。
「４」次フェーズの計画：要求分析の計画や開発計画、テスト計画を作成する
というフェーズを4回繰り返します。
７：プロトタイプモデル
ユーザの要求は代わりやすいものです。具体化してくると「こんなはずではなかった」ということになりがちです。これは、ユーザの要求を上手に汲み取れていないこと、すなわち、ユーザと開発者との認識のズレが原因です。
そこで、早い段階で試作品（プロトタイプ）を組み立てて、ユーザに具体的なイメージを持ってもらう方法を使うと効果的です。このような方法をプロトタイピング技法と言います。ユーザは、試作品を見て、改良点、変更点を指摘します。開発者は、その指摘を反映させてシステム開発を進めます。
プロトタイプモデルはプロトタイピング技法を主体としてシステムの開発をすすsめる方法です。
８：アジャイル開発
アジャイル開発は、従来のウォータフォールモデルでは難しかった開発期間nの短縮や変動する要求への柔軟な対応、品質の向上言うなどを目的とした、迅速かつ適応的な開発手法の総称です。アジャイル開発で用いられる手法や活動をプラクティスと言います。さまざまなプラクティスがありますが、総じてみれば、イテレーションあるいは、スプリントと呼ばれる短い開発サイクルを繰り返して開発を進めることが特徴です。
アジャイル開発に関する用語を下記にまとめます。
①XP（エクストリームプログラミング）：設計を厳格に行い、早い段階で使用を確定させると言う従来の設計手法に対し、仕様の変化は常に起こり得るものとして受け入れ、柔軟性やスピードを重視して、コーディング（プログラムを書く）、テスト、再設計を繰り返す量に開発を進める。
②ペアプログラミング：２人のプログラマがペアになって１つのプログラムを開発する。その場で相談やレビュー、助言などを行いながら開発を進めることで、品質の向上や知識の共有を行う。XPの主要なプラクティスの１つである。
③継続的インテグレーション：単体テスト（ユニットテスト）が完了したプログラムをすぐに結合して結合テストを行う。XPの主要なプラクティスの１つである。
④テスト駆動型開発：プログラムを書く前にテストケースを作成し、このテストをパスするようにプログラムを開発する。
⑤スクラム：スプリントと呼ばれる短い周期で機能の実装と評価を繰り返しながら開発を進める。開発メンバは、デイリースクラムと呼ばれる毎日のミーティングで進捗確認や情報共有を行う。チーム内でのコミュニケーションを密に取りながらチーム一丸となって開発を進めることが特徴です。
⑥リファタリング：完成しているプログラムの性能向上や保守性向上などを目的として、プログラムの外部から見えた動作は変えずに、プログラムの内部構造（ソースコード）を整理、改善することである。重複したコード、不要なコードなどを取り除イタリ、変数名をわかりやすいものに変更したりする。
９：リバースエンジニアリングとリエンジニアリング
リバースエンジニアリングは、下流工程の成果物（ソースコードなど）から上流工程の成果物（内部設計書、外部設計書、要求仕様書などの仕様書）を生成することです。
本来はあって花いらないことなのですが、実際の現場では、現在動作しているシステムの最新の仕様書がなく古いままであったり、最悪の意場合には、仕様書そのものを紛失してしまっていたりすることがあります。このような場合、リバースエンジニアリングを行い、仕様書を作成します。
リバースエンジニアリングによって得られた仕様書に改良を加えて新しい仕様書を作成し、その仕様書に基づいて製品を作ることをリエンジニアリングと言います。