システム開発の流れ
工程 | やること |
RFI(Request For Information) 情報提供依頼 | 発注者が、システム化にあたっての最新の技術動向などの情報提供を依頼する。 |
RFP(Request For Proposal) 提案依頼 | 発注者が、システム化にあたっての予算や諸条件の提案をベンダー(システム業者)に依頼する。 |
提案書・見積書を作成 | ベンダーが、RFPに対してシステムの概要や予算を提案書・見積書の形で返答する。 |
ベンダー選定 | 発注者が、RFPに対する提案書・見積書を元に、発注先のベンダーを決定する。 |
契約 | 発注者とベンダーが契約締結する。 |
契約を締結した後は、要件定義、設計、製造を行う。
工程 | やること |
要求定義 | 発注者がシステム化の目的や必要な機能の概要を定義する。 |
要件定義 | 発注者とベンダーが、要求定義を精査して必要な機能や性能を定義し、要件定義書を作成する。 |
外部設計 | ベンダーが、要件定義書を元に、UI設計・帳票設計を行う。 バーコードやハンディターミナルを使用する場合は、その設計も行う。 |
内部設計 | ベンダーが、要件定義書・外部設計書を元に、データベース設計、機能設計を行う。 |
プログラム設計 | ベンダーが、プログラムをどう作るかという視点から、クラス設計などを行う。 |
製造(プログラミング) | 設計書をもとにプログラミングを行う。 |
外部設計と内部設計について
・外部設計とは、システムを外部から見たときの設計である。つまり、利用者が実際に使用する入出力が設計対象となる。
・内部設計とは、システムを内部から見たときの設計である。つまり、外部設計で決まったUIや帳票を実現するために、開発者がシステム内部の構造を決定するのが内部設計である。
プログラムを製造した後は設計通りの実装になっているかテストする。
工程 | やること |
単体テスト | モジュール単位で行う、プログラム設計に対するテスト。 |
結合テスト | モジュール同士を繋げたときに設計通りに動くかテストする。 |
システムテスト | 機能面では、想定する業務シナリオがシステム全体を通して実行できるか確認する。 非機能面では、性能試験も行う。 |
運用テスト | 実運用を想定したテスト。 |
上記はあくまで一例である。現場によって内部設計と呼ばれる物を外部設計でやっていたり、要件定義の中で外部設計までやることもある。
システムの開発の進め方
複数のモデルがあるが、厳密に区別できるものではない。
ウォーターフォールモデル
システム全体を要件定義→設計→製造→テストと順番に進めていく進め方。
最後まで発注者はシステムを見ることができないため、出来上がったものを見て、思ってたのと違ったということになることがある。
最も古典的な進め方で、現在でも最も多く利用されている。
プロトタイピングモデル
設計段階でに試作品(プロトタイプ)を作って発注者に見せることで、発注者とベンダーの認識のズレを解消しておく手法。
プロトタイプを作った後で、設計→製造→テストを進める。
スパイラルモデル
システム全体を開発しやすい単位(機能)に分割して、分割した機能ごとに設計→製造→テストを進めていく手法。
レビューについて
各工程の成果物を検証すること。
レビュー手法 | やり方 |
ウォークスルー | 成果物の作成者がレビュアーに説明し、随時指摘を得る進め方。 |
インスペクション | レビュアーごとに検証観点を決めておくやり方。 |
ラウンドロビン |