4.システム開発工程のフェーズ

4-1.フェーズの例

システム開発工程のフェーズは、開発標準やプロジェクトによって異なりますが、全体流れは共通しています。以下がフェーズの具体例です。フェーズの説明は誤解を恐れずに簡潔にしています。詳しくは別ページにて説明します。

(1) よく見かける例

以前の情報処理技術者試験に近いフェーズ分けです。某SI企業の20年前の開発標準もこの様な分け方でした。最近でも多く使われていると思います。

①要件定義

どんなシステムが必要なのかを検討し、必要な機能やハードウェア構成などを「要件」として定義します。ユーザ企業とベンダ企業が要件について合意します。

②外部設計(基本設計)

システムの機能ごとに画面、帳票、対外システム接続などを設計します。ベンダ企業はユーザ企業に設計書をレビューしてもらいます。

③内部設計(詳細設計)

システムの機能を実現するためのソフトウェアの内部構造を設計します。

④製造

内部設計に基づき、コーディングや単体テストなどを行います。

⑤結合テスト

画面、帳票、対外システム接続などが正しく動作することを確認します。

⑥システムテスト

各機能が連携して、システムとして正しく動作することを確認します。

⑦ユーザテスト

本番同様のシステム環境で、ユーザ企業がテストします。システムが要件を満たし、業務で使用できることを確認します。

(2) 共通フレーム2013を反映した例

共通フレーム2013(SLCP-JCF 2013)というシステム開発工程のガイドラインがあります。共通フレーム2013ではフェーズ自体は定義していませんが、そのガイドラインを反映したのが以下の例です。共通フレーム2013ではフェーズ名を定義していませんので、筆者が名づけたものです。某SI企業の最近の開発標準がこれに近いものでした。
(1)との一番の違いは、外部設計の一部を別フェーズとしている点です。

①業務要件定義

どんなシステムが必要なのかを検討し、必要な機能やハードウェア構成などを「業務要件」として定義します。ユーザ企業とベンダ企業が業務要件について合意します。

②システム要件定義

画面、帳票、対外システム接続などのシステムの外部仕様を「システム要件」として定義します。ユーザ企業とベンダ企業がシステム要件について合意します。

③設計

システム要件を実現するための機能設計やクラス設計などを行います。このフェーズは「機能設計」「画面設計」「クラス設計」などに分割しても構いません。

④製造(プログラミング)

設計に基づき、プログラムのコーディングや単体テストなどを行います。

⑤結合テスト

画面、帳票、対外システム接続などが機能単位で正しく動作すること、あるいは機能間の連携に問題が無いことを確認します。

⑥システムテスト

各機能が連携して正しく動作し、システム要件を満たすことを確認します。

⑦ユーザテスト

本番同様のシステム環境で、ユーザ企業がテストします。システムが業務要件を満たし、業務で使用できることを確認します。

(3) 移行に関する作業

移行とは完成した新システムを稼動させるための作業ですが、上記の例には移行に関する内容は含まれていません。
移行には、設計や準備、移行リハーサル、移行実施などといった作業が必要で、作業規模が大きい場合は別プロジェクトとして進める場合もあります。

(4) 運用に関する作業

要件定義では運用に関する要件も定義します。設計ではソフトウェアの設計だけでなく運用の設計も必要です。例えば、バッチ処理を何時から起動するか、運用に関する作業をどの権限の人がいつ行うのか、障害発生時にどのように対処するのか、など検討しておきます。
他にも、運用マニュアルの作成や利用者への教育などが必要となる場合もあります。

4-2.ウォーターフォールモデルとV字モデル

(1) ウォーターフォールモデル

システム開発工程の考え方を表す言葉に「ウォーターフォールモデル」があります。

ウォーターフォールモデルの説明図

これは滝の水は決して逆流しない事から、工程も後戻りはしない事を明確に表しています。実際には前のフェーズで問題が見つかると後戻りすることもあるのですが、その場合プロジェクトで想定していない大きな工数が追加となってしまいます。つまりは失敗プロジェクトです。
ちなみに日本人が「滝」をイメージする時は、「華厳の滝」や「那智の滝」の様な水が垂直落下する様子を連想しますが、ここでいう滝は「袋田の滝」や「竜頭の滝」の様な水が段々に流れていく様子を表しています。海外では滝というと後者をイメージすると何かで聞いた記憶があります。

(2) V字モデル

筆者が新人だった20年前には習わなかった(教科書にも書いてなかった)のですが、今は「V字モデル」という概念を教わります。これはウォーターフォールを変形したもので、設計のフェーズとテストのフェーズが関連付けられていることを強調しています。

V字モデルの説明図

ウォーターフォールモデルとV字モデルは実態は同じです。何を強調して説明したいかによって表現を変えているだけです。

4-3.ウォーターフォールモデル以外の開発手法

理解しやすく実践的なウォーターフォールモデルですが、問題点もあります。一番の問題点は上流工程での誤りや検討漏れが下流工程で見つかると大きな手戻りが発生することです。上流への手戻りをしないことから「ウォーターフォール」と名付けられていますが、現実には手戻りの発生は起こりえます。
そのため、1990年代には「プロトタイプモデル」や「スパイラルモデル」、2000年代には「反復型開発」や「アジャイル開発」が注目されました。
それぞれの開発手法には長所短所がありますが、全てに共通なのはウォーターフォールモデルが基本形であることです。ウォーターフォールモデルを正しく理解できていない人が他の方法を実践しても失敗します。そしてウォーターフォールモデルを正しく理解できている人は大手SI企業でも少数なのが現実です。
また、ウォーターフォールモデルに弱点があるのも事実です。実際に成功するプロジェクトはウォーターフォールモデルを単純に実行するだけではなく、プロジェクトマネージャの創意工夫によってリスクを回避しているものです。

カテゴリー: システム開発の基礎 タグ: , , , ,