【UPで学ぶ】システム開発プロセス

ここでは、統一ソフトウェア開発プロセス（UP：Unified Process）の３つの考え方

• ユースケース駆動プロセス
• アーキテクチャ中心プロセス
• 反復的でインクリメンタルなプロセス

を活かしたシステム開発のプロセスについて次の観点で解説します。

• システム開発のコンセプト
• システム開発の工程
• システム開発のフェーズ
• 関連動画

統一ソフトウェア開発プロセスとは、UML(統一ソフトウェア開発言語）を開発したグラディ・ブーチ（Grady Booch）、ジェームズ・ランボー（James E. Rumbaugh）、イヴァー・ヤコブソン（Ivar Jacobson）を中心に開発されたソフトウェア開発プロセスです。
ブーチ、ランボー、ヤコブソン（スリーアミーゴという愛称で親しまれています）は、それぞれ独自に提唱していたオブジェクト指向開発の方法論のうち、表記法をUML（Unified Modeling Language）、開発プロセスをUP（Unified Process）として統一しました。
なお、本記事は、書籍「UMLによる統一ソフトウェア開発プロセス」を参考にしています。


それから、アプリケーションを設計する重要な考え方としてドメイン駆動設計があるので、合わせて参照してください。

システム開発のコンセプト

まず、システム開発の柱となる考え方を次の観点で説明します。

• 統一ソフトウェア開発プロセスの３つのコンセプト
• システムをモデル化するときの３つの視点
• システム開発の３つのアプローチ

それぞれ見ていきましょう。

統一ソフトウェア開発プロセスの３つのコンセプト

統一ソフトウェア開発プロセスの３つのコンセプトは次の３つです。

• ユースケース駆動プロセス
• アーキテクチャ中心プロセス
• 反復的でインクリメンタルなプロセス

ユースケース駆動プロセス

システムは、ユーザーに価値を提供すること目的として存在しています。
ここでいう、ユーザーとは、システムと相互作用する人またはもの（対象のシステムの外部にある別のシステムなど）を表します。
統一ソフトウェア開発プロセスでは、ユーザーにとって価値のある結果をもたらす一連のアクションをユースケース（システムの使い方）として表します。
このユースケースを起点としてシステム開発の各工程が進められる考え方をユースケース駆動プロセスといいます。
ユースケース駆動プロセスでは、まず、要件定義で、システムが実現すべき機能をユースケースとして定義し、そのあとの工程で、その機能をどう実現するのか分析、設計、実装していきます。

ユースケース駆動プロセスによって、ユーザーに提供する価値を実現するプロセスとしてシステム開発を進めることができます。

アーキテクチャ中心プロセス

ユースケースは、システムが実現すべき機能を表しますが、その機能を実現するシステムの構成要素の仕組（構造と振舞）を表すのがアーキテクチャです。
システムのアーキテクチャは、システムの設計思想、および、それに基づいたシステムの基本的な仕組のことです。
基本的な仕組とは、詳細を省いた土台となる骨組みを表します。
システムに求められる要件を機能要件と、非機能要件に分けるならば、機能要件からユースケースが導かれ、非機能要件がシステムの設計思想になり、アーキテクチャを規定します。
非機能要件とは、システムの品質に関する要件と、課題を解決するために予め決められた、ソフトウェアを実行するIT基盤や、導入のための考慮事項などの制約条件のことです。

統一ソフトウェア開発プロセスでは、建築物と同じように、まず、システムの骨組みであるアーキテクチャ（土台）を設計し、それに肉付けしてシステムを完成させることで、より堅牢（Robust）なシステムを構築することができるという考え方に基づいています。

より本質的で変わりにくいアーキテクチャと、変化しやすい具体的な実現手段（テクノロジーなど）を分離し、環境の変化に応じて実現手段を交換できるようにすることで、環境の変化に強い柔軟なシステムを構築することができます。

反復的でインクリメンタルなプロセス

統一ソフトウェア開発プロセスの３つ目のコンセプトは、反復的でインクリメンタルなプロセスです。
システム開発を進める方法には、ウォーターフォール型開発と反復型開発があります。

ウォーターフォール型開発

ウォーターフォール型開発とは、ソフトウェアの開発工程を時系列に分けて、順番に開発していく方法です。
ソフトウェア開発が、工程ごとに、あたかも滝(waterfall)のごとく水が上から下に落ちていくように進んでいくのでウォーターフォール型開発と呼びます。

ウォーターフォール型開発では、一つ工程を一度で終わらせる計画を立て進捗を管理するので、原則として、前工程が完了しないと次工程に進みません。
なので、ウォーターフォール型開発のメリットは、開発工程が順番に流れていくシンプルな構造になっており進捗管理しやすいということです。
逆に、ウォーターフォール型開発のデメリットは、比較的、開発のリスクが高いということです。
なぜでしょうか？
ウォーターフォール型開発の問題点は前工程に間違いがないことを前提にしている点です。
顧客の要求を事前に詳細に定義することは非常に困難です。
なぜならば、ソフトウェアは概念で変わりやすいものなので、それを明確な形で表すことが困難だからです。
なので、顧客の要求を徹底的に確認したにも関わらず、下流工程になって始めて顧客の目に見えるものが出来上る場合、それを見た顧客から修正要望が出ることがあります。
この要望に応えるには、時間をかけて進めてきた工程を、後に戻してやり直す必要があります。
開発の後戻りにより、開発の予算や納期をオーバーしてしまう可能性があるのです。

反復型開発

反復型開発とは、ソフトウェアを小さな単位に分けて、小単位で一連の開発工程を繰り返し、段階的にリリースしていく開発方法です。
この小さな単位をイテレーション（反復）といいます。

反復型開発のメリットは、比較的、開発のリスクが低いということです。
反復型開発の場合、小さな単位で顧客の目に見えるものが出来上がっていくので、その都度、顧客の要求が明確になり、その要求を製品に反映していくことができます。
なので、開発の初期段階から顧客の要求とのズレを調整しいくことができ、ウォータフォール型開発のように、後工程で、いきなり顧客の要求との大きなズレが発覚することは、まずありません。
それでは、反復型開発デメリットは何でしょうか？
それは、進捗管理が難しいということです。
反復型開発の場合、小さな開発単位が反復しながら進んでいくとともに、状況状況に合わせて反復を設計する必要があるので進捗管理が複雑です。
縦軸に開発のリスク、横軸に時間をとってウォータフォール型開発と反復型開発の違いを表すと下図のようになります。

ウォータフォール型開発が開発の後半までリスクが残っているのに対し、反復型開発は、初期段階からリスクが下がっていることがわかります。
以上より、ウォーターフォール型開発と反復型開発を、

• 進捗管理の難易度
• 開発のリスク

という観点から比較すると次のようになります。

ウォーターフォール型開発のプロセスは、建物の建築プロセスに似ています。
建物の場合、建築様式がほぼ決まっており、建築過程で顧客の要求がコロコロ変わることもないので、要求、設計、施工という順で問題なく進めることができると思います。
ビジネスの変化も少なく、先行きが予測できた時代は、顧客の要求も一定で、ソフトウェア開発も建築業のプロセスで進めることができたと思いますが、ビジネスの変化が激しく、先行き不透明な昨今、ビジネスの変化に合わせて顧客の要求も変化するので、ソフトウェア開発に建築業のプロセスを適用することが、事実上、難しくなってきました。
統一ソフトウェア開発プロセスでは、、このような時代の変化を受けて、顧客の要求の変化に機敏（アジャイル）に対応できるサービス業のプロセスに近い反復型開発をベースに組み立てられています。
ここで、反復的でインクリメンタルなプロセスについて明確にしておきましょう。
反復的（イテラティブ）プロセスと漸増的（インクリメンタル）プロセスを分けて考えます。
反復的プロセスでは、サイクルを繰り返すごとに、システム全体の濃度が上がるように仕上げていきます。
システム全体の濃度を上げるとは、システムのアーキテクチャを構成する要素であるモジュール（ソフトウェア部品）の完成度を段階的に上げていくということです。
一方の漸増的プロセスでは、システムを、ユースケースなどの小さな機能単位に分解し、サイクルを繰り返すごに要素を一つづつ仕上げていきます。
反復的でインクリメンタル（漸増的）なプロセスとは、この２つの組み合わせで、骨組みであるアーキテクチャが固まったあとは、ユースケース一つ一つを漸増的に仕上げていき、システム全体を反復的に肉付けしていくという方法です。

これは、ユースケース駆動とアーキテクチャ中心というコンセプトを活かした反復型開発で、ユーザーに対する価値を持続的に提供し続けられるシステムを構築するためのモデルになっているのです。
ここでは、反復的でインクリメンタルなプロセスを開発の工程（縦）と開発のフェーズ（横）に分けて解説します。


なお、反復型開発の一種に、アジャイル開発があります。
通常の反復型開発が開発計画を重視するのに対し、アジャイル開発はソフトウェアが顧客に提供する価値を重視しています。
アジャイル開発については、記事アジャイル開発とは何かを参考にしてください。

さて、統一ソフトウェア開発プロセスの３つのコンセプトをまとめると、システム開発プロセスは次のようになります。

• 方向づけフェーズでシステムの要件を定義し、
• 推敲フェーズでシステムの骨組みであるアーキテクチャを設計し、
• 構築フェーズで、実装を通して、反復でインクリメンタルにシステムの骨組みを肉付けしていき、
• 移行フェーズでテストを通して、システムの要件が満たしているか検証してリリースする。

統一ソフトウェア開発プロセスによって、環境の変化に機敏に適応できるシステムを確実に構築することができるのです。

システムをモデル化するときの３つの視点

次に、システム開発の工程を分解するときの考え方として、システムをモデル化するときの３つの視点について説明します。
モデル（模型）とは、現実のシステムの特別な一面を簡略化した形で表したものです。
ここでは、この特別な一面として、

• 外部的視点と内部的視点
• 物理的視点と論理的視点
• 動的視点と静的視点

でシステムを観た場合について紹介します。

外部的視点と内部的視点

まず、外部的視点と内部的視点でシステムをモデル化する場合について説明します。

外部的視点

外部的視点とは、システムの外部要素に、システムがどう働きかけるかを観る視点です。
外部的視点で、システムの外部要素に対してシステムが提供する機能をモデル化します。
統一ソフトウェア開発プロセスは、システムの機能をユースケースとして可視化します。
UMLでは、外部的視点でユースケース図を描きます。

内部的視点

システムの内部で、システムの機能がどのように実現されるかを観る視点です。
内部的視点で、システムが機能を実現する仕組をモデル化します。

外部的視点と内部的視点は、外部要素に対するインターフェース（What：何をするのか）と、その実現方法（How：どのようにするのか）を分離します。
外部要素に対してインターフェースのみ公開し利用させることで、内部の実現方法やデータを相手から隠蔽し（ブラックボックス化）自由に交換することができるようになり、変更による影響を最小にする保守性の高い仕組みを実現することができます。
また、インターフェースと実現手段のセットをモジュールとして再利用することができるので生産性が向上します。
システム開発では、外部設計と分析および設計という工程を分けて、インターフェース（What）と実現手段（How）を分けて設計します。
※
なお、システムを構成する要素も一つのシステムと考えた場合、相互作用する相手の要素が外部要素になります。
システムを構成する要素を、インターフェースと実現手段で分けてモジュール化することで、要素同士が疎結合になり、生産性、および、保守性が上がります。
記事変化に強い企業基盤・モジュール化も参考にしてください。

物理的視点と論理的視点

次に、物理的視点と論理的視点でシステムをモデル化する場合について説明します。

物理的視点

物理的視点とは、物理法則にかなっているシステムの様子を観る視点です。
物理的視点で、システムの物理的な仕組をモデル化します（物理モデル）。
UMLでは、配置図やコンポーネント図によって、システムの物理的な仕組を描きます。

論理的視点

論理的視点とは、論理（物事の間にある法則、筋道）にかなっているシステムの様子を観る視点です。
なので、必ずしも物理法則にかなっていなくても筋道が通っていればよいということになります。
論理的視点で、システムの論理的な仕組をモデル化します（論理モデル）。
UMLでは、クラス図によって、システムの論理的な構造、相互作用図や状態マシン図によってシステムの論理的な構造を描きます。

論理的視点と物理的視点は、変わりにくい論理的な仕組と、変わりやすい物理的な仕組を分離します。
時代とともにテクノロジーが進化した場合、それにともなって物理的な仕組は変化しますが、論理的な仕組は時代を超えて再利用することができます。
論理的な仕組と物理的な仕組を分けて考えるアーキテクチャにMDA（Model-Driven Architecture：モデル駆動アーキテクチャ）があります。
MDAでは、システムを構築するとき、次の３つのモデルを分けて考え、CIM→PIM→PSMという流れで設計することで、より堅牢なシステムをつくることができるとしています。

• CIM（Computation Independent Model）
  計算機処理に依存しないモデル。業務モデル。
• PIM（Platform Independent Model）
  IT基盤に依存しないモデル。論理モデル。
• PSM（Platform Specific Model）
  IT基盤に特化したモデル。物理モデル。

システム開発では、分析でシステムを論理的に分析しPIMを設計し、設計でIT基盤に依存したPSMを設計します。
なお、CIMは、要件定義の段階でつくります。

IT基盤に依存した設計モデル（PSM）は環境の変化に応じて変わっても、論理的な分析モデル（PIM）は再利用できます。

動的視点と静的視点

最後に、動的視点と静的視点でシステムをモデル化する場合について説明します。

動的視点

動的視点とは、システムが動いている状況を、視点を移動させながら観る視点です。
動的視点で、システムの機能や振舞をモデル化します。
UMLでは、ユースケース図によって、システムの機能、相互作用図や状態マシン図によってシステムの振舞を描きます。

静的視点

静的視点には次の２つの場合があります。

• 動いている途上の断面を観る場合
• 様々な状況を一貫して観る場合

静的視点で、システムの構造をモデル化します。
UMLでは、オブジェクト図によって、システムの動いている途上の断面を表す構造、クラス図によって、様々な状況を一貫して観た構造を描きます。

システム開発の３つのアプローチ

統一ソフトウェア開発プロセスの３つのコンセプト、システムをモデル化するときの３つの視点を合わせてシステム開発のアプローチをまとめると、次のように「機能」、「構造」、「振舞」の３つのステップで開発を進めることになります。

1. 機能
   まず、外部的視点で、システムがユーザーに提供すべき価値をユースケース（何をするのか）としてモデル化します。
2. 構造
   次に、内部的視点で、ユースケースを実現するシステムの構成要素の構造（誰が実現するのか）を明確にします。
3. 振舞
   最後に、システムを構成する要素の振舞（どのようにユースケースを実現するのか）を分析することで、システムの構造の妥当性を検証します。

このアプローチをシステム開発の工程で分けると次のようになります。

システム開発の工程

続いて、統一ソフトウェア開発プロセスの反復的でインクリメンタルなプロセスのシステム開発の工程（縦）について解説します。

プロセス品質
品質には、製品やサービスの品質であるプロダクト品質のほか、製品やサービスを生み出すための過程にも品質があり、これをプロセス品質といいます。
品質を考える場合、プロダクト品質だけでなく、プロセス品質を考えることも重要です。
高品質な製品が一つ出来たとしても、それが偶然の産物であっては意味がありません。
安定して高品質な製品やサービスを生み出し続けるためには、生産の過程そのものが高品質である必要があります。
生産工程の細分化と分業が進む昨今、生産開始段階から各工程でしっかり品質を作り込んでいくという姿勢が大変重要です。

ここでは、システム開発の工程を次のように分けて説明します。

1. 要件定義
   システムの目的（存在意義）を明確にし、それを実現するためにシステムに求められる要件（必要な条件）を定義します。
2. 外部設計
   外部設計では、システムのユーザーインターフェースを設計します。
3. 分析
   分析では、システムのユースケースを実現する内部の論理的な仕組を分析します。
4. 設計
   設計では、システムのユースケースを実現する内部の物理的な仕組を設計します。
5. 実装
   設計の結果を受けてシステムを実装します。
6. テスト
   システムが要件を満たし、業務で運用できるか検証します。

なお、ここいうシステム開発の工程は、エンジニアリングのプロセスで、システム開発のマネジメントを行うプロジェクト管理プロセスは含みません。

要件定義

まず、システムの目的（存在意義）を明確にし、それを実現するためにシステムに求められる要件（必要な条件）を定義します。
上述したシステム開発の３つのアプローチでいうと次の赤い枠の部分になります。

ここでは、システムが解決すべき業務課題と、その解決方法によって、システムの要件を定義します。
ビジネスの目的は、顧客を中心としたステークホルダーに価値を提供し続けることです。
ビジネスの目的を実現するためには多くの業務課題を解決する必要があります。
システムは、業務課題を解決するための有効な手段です。
なので、

1. システムが解決すべき業務課題は何か
2. システムは業務課題をどう解決するか

というステップで、システムの目的と要件を考えます。

システムの目的

システムの目的は、特定の業務課題を解決することです。
結果的に、顧客を中心としたビジネスのステークホルダーに価値をもたらします。
なので、システムは、ビジネスの中で考えると、業務課題を解決する一つの手段という位置づけになります。
さて、業務課題を明確にするにはビジネスアーキテクチャ（ビジネスの仕組）を考えることが有効です。
特に、顧客に価値を届けるバリューチェーンを構成する活動の流れを業務フローとして可視化することで、どこで問題が発生しているのか、業務課題の発生源を明らかにすることができます。

システムの要件

システムの目的が定まったら、それを実現するためにシステムに求められる要件を定義します。
システムに求められる要件は、

• 機能要件
• 非機能要件

に分け考えます。

機能要件

業務課題を解決するために必要なシステムの働きを機能要件として定義します。
システムの機能は、システムがユーザーにどのような価値を提供するかという外部的な観点で定義します。
統一ソフトウェア開発プロセスでは、ユーザーにとって価値のある結果をもたらす一連のアクションをユースケースとして表します。
UMLのユースケース図の例

UMLのユースケース図を使うことで、システムが価値を提供する相手であるユーザーと、提供する価値をアクターとユースケースの関係で表すことができます。
なお、ビジネスアーキテクチャの業務フローからシステムのユースケースを導くことで、業務課題を解決するためのシステム機能を明確にすることができます。

次に、非機能要件ですが次の３つに分けて定義することができます。

• データ要件
• 品質要件
• 制約条件

データ要件

課題を解決するために記録、活用すべき事実（データ）を明確にします。
クラス図やER図でドメインモデル、あるいは、概念データモデルをつくることでデータ要件を明確に定義することができます。
ドメインモデル（概念データモデル）は、データを発生させるビジネスの実体（エンティティ）の関係を構造化することで作成します。
※ビジネスの実体には、価値を生む資産や活動があります。
UMLのクラス図で描いたドメインモデル（概念データモデル）の例

クラス図のクラスをエンティティを表すアイコンを使って描くこともできます。

参考記事
クラス図を使った概念モデルの作り方
【DMBOKで学ぶ】データモデリング

品質要件

システムに求められる品質の要件を定義します。
ISO9126に定義されているソフトウェアの品質特性の例を示します。

• 合目的性(suitability)
  ユーザーの要求とシステムの仕様（要件）はどの程度合致しているか。
  システムを検証する場合、次の２つの観点を考えます。
  • 仕様適合性
    システムが仕様に適合している度合い。
    仕様適合性の検査はVerificationで、システムテストを通して検証します。
  • 妥当性
    システムが顧客を満足させるものになっている度合い。
    仕様適合性が確認されても、妥当であるとは限りません。
    仕様自体が不適切である可能性があるからです（仕様バグ）。
    仕様適合性の検査はValidationで、運用テストを通して検証します。

  システムは、合目的性、仕様適合性、妥当性を満たすことで、顧客が受け入れる完成品になります。

• 効率性(efficiency)
  システムの機能を実行する時間や使用するコンピュータ資源の量は適切か。
• 使用性(usability)
  使い勝手は良いか。
• 信頼性(reliability)
  システムが正常に動作し続けられるか。
  信頼性を上げるには、システムがその規模の変化に対して柔軟に対応できる度合い、スケーラビリティ（scalability）を高める必要があります。
  故障のしにくさは、故障と故障の間の平均時間、平均故障間隔（MTBF：Mean Time Between Failures）で測ることができます。
  すべての時間の中で稼働している時間の割合を可用性（availability）とし、稼働率で測ることができます。
  稼働率=MTBF/(MTBF + MTTR）。
  なお、障害発生時に稼働を継続する能力（レジリエンス）を対障害弾力性といいます。
• 安全性(security)
  不正や誤謬による情報漏洩や資源破壊を防げるか。
• 保守性(maintainability)
  既存機能の修正や新しい機能追加が迅速にできるか。
  故障から復旧までの平均時間、平均修理時間（MTTR：Mean Time To Repair）で測ることができます。
• 移植性(portability)
  WindowsからMac、PCからタブレットやスマートフォン、他プログラム言語、OSやH/W、地域の変更など環境を変えても正常に動作するか。
• 相互運用性(interoperability)
  他システムとの間で、データやコマンドをスムーズにやりとりできるか。

システム品質の一部としてデータの信頼性やセキュリティに関する要件も定義します。

制約条件

業務課題を解決するために予め決められた、ソフトウェアを実行するIT基盤の構成や、導入のための考慮事項などを制約条件として定義します。
例えば、企業全体を最適化するためのアプリケーションアーキテクチャやテクノロジーアーキテクチャがあり、そのために使用することが決まっているマイクロサービスやIT基盤は開発の制約条件になります。

外部設計

外部設計では、システムのユーザーに対するインターフェース（以下、ユーザーインターフェース）を設計します。
上述したシステム開発の３つのアプローチでいうと次の赤い枠の部分になります。

ユーザーは、システムが価値を提供する相手であり、システムと相互作用する人またはもの（対象のシステムの外部にある別のシステムなど）を表します。
ユーザーが人の場合、ユーザーインターフェースは画面になりますが、その場合、外部設計は次のアクションより構成されます。

• ユースケースの詳細化
• 画面構成の設計
• 画面イメージの作成
• 画面遷移の設計

これらのアクションは互いに関連するため並行して進めます。
次に、ユーザーがシステムの場合、ユーザーインターフェースは、API（アプリケーションプログラミングインターフェース）になります。
その場合、ユースケースを詳細化した後、APIを洗い出すために、シーケンス図を描いてユースケースを分析します。
システムの場合の外部設計については、アプリケーションアーキテクチャの外部設計を参照してください。

ユースケースの詳細化

ユースケース単位に、次の内容を定義してユースケースを詳細化します。

• 事前条件
  ユースケースを開始するときの条件。
• イベントフロー
  アクターとシステムの相互作用。
  イベントフローは、基本フローと代替フローに分けて記述します。
  • 基本フロー
    例外などがない通常の流れ。
  • 代替フロー
    例外が発生した場合のフローなど、基本フローを代替する流れ。

  イベントフローは、外部的視点に立ち、

  • アクターが〜すると
  • システムは〜する

  というように、アクターとシステムの相互作用のみ記述し、システムの内部でどうのような処理を行うかは記述しないようにします。
  また、相互作用を記述するとき、「システムは注文確認画面を表示する」のように画面構成や画面イメージで定義した画面名を使うことで成果物の一貫性を保つことができます。

• 事後条件
  ユースケースを終了するときの条件。

ユースケースの詳細を記述したものを「ユースケース記述」といいます。
上記ユースケース図の「商品の注文」ユースケースのユースケース記述例

1. 事前条件
   • 会員がログインしていること
   • システムは商品注文画面を表示していること
2. メインフロー
   1. 会員が商品注文画面で商品を押下すると、システムは商品詳細画面を表示する。
   2. 会員が商品詳細画面で商品を選択すると、システムは商品注文画面を変更する。
   3. 会員が商品注文画面で注文を確定すると、システムは注文完了画面を表示する。
3. 代替フロー
   a.３で、注文が確定できない場合、#2「注文できませんでした」というメッセージを出力する。
4. 事後条件
   注文が登録されていること。

次に、ユースケース記述に基づいて、システムテスト、および、統合テストの受け入れ基準を作成します。
受け入れ基準は、ユースケース記述を具体的に表現したもので、これをユースケースシナリオと言います。
例えば、上記「商品の注文」ユースケースのユースケースシナリオの場合、ユースケース記述の具体的な商品番号や注文番号を記述します。
システムテスト、および、統合テストでは、ユースケースシナリオが正しく遂行され、指定された商品番号の商品が、指定された注文番号で注文できるか検証します。

画面構成の設計

システム全体の画面構成を設計します。
画面を、バウンダリー（境界）を表すクラスのアイコンを使って表し、クラス図で画面構成を描くこともできます。
クラス図で画面構成を表した例

画面イメージの作成

画面構成を構成する個々の画面単位に、画面のイメージを作成します。
画面イメージはドローツールを使って描いても良いですが、Webアプリなどシステムの実現方式が制約条件として決まっている場合は、HTMLを使って作成してもよいです。

画面遷移の設計

ユースケースの詳細に整合するかたちで画面遷移を作成することで、ユーザーインターフェースの振舞を明確にすることができます。
UMLの状態マシン図を使って画面遷移を表すことができます。
上記ユースケース図の「商品の注文」の画面遷移を状態マシン図で表した例

分析

分析では、システムのユースケースを実現する論理的な仕組を分析します。
上述したシステム開発の３つのアプローチでいうと次の赤い枠の部分になります。

分析は次のアクションより構成されます。

• ドメインの分析
• ユースケースの内部分析
• クラスの分析
• データの分析

ドメインの分析

最初に、システムが関連する業務の活動領域（ドメイン）を分析します。
ドメインは、システムの論理的な構成単位になります。
記事ドメイン駆動設計・戦略的設計も参考にしてください。
次の図は、バリューチェーンを構成する一般的な活動領域です。

要件定義で示した「商品の注文」ユースケースを含むドメインは、この中の「販売」になります。
しかし、商品を販売する場合、顧客や商品が必要になるので、「顧客管理」、「商品管理」ドメインも必要になります。
これらのドメインの関係をUMLのパッケージを使って表すと次のようになります。

「販売」ドメインは、顧客、商品を管理する「顧客管理」、「商品管理」ドメインに依存します。
なお、販売ドメインの中に、上記の「注文」エンティティ、「注文明細」エンティティが含まれ、「顧客」エンティティは「顧客管理」ドメイン、「商品」エンティティは「商品管理」ドメインに含まれます。

ユースケースの内部分析

ここでは、

• ユースケースを実現するために必要なクラスを洗い出し、
• クラス間の関係を考え（構造化）、
• そのクラス構造で本当にユースケースが実現できるか検証します。

UMLを使う場合、クラス図でクラス構造を可視化し（下図の②）、相互作用図を使って、そのオブジェクトの振舞を分析する（下図の③）ことで、クラス構造の妥当性を検証します。
ユースケースを分析するとき作成するクラス図や相互作用図を分析モデルと呼びます。
※ 相互作用図には、シーケンス図とコミュニケーション図がありますが、シーケンス図を使うことが多いです。

さて、ユースケースを分析するときに有効な方法の一つにロバストネス分析があります。
これは、ユースケースを実現するクラスを、バウンダリ、コントロール、エンティティという３つの役割に分け、バウンダリ→コントロール→エンティティというアクセスの流れをつくることで変化に強い（Robustな）内部構造にするという方法です。

• バウンダリ（Boundary）
  ユーザーや外部システムなどシステムの外部要素と相互作用する責務を担うクラス。
  外部要素がユーザの場合、画面構成のクラスを使用する。
• コントロール（Control）
  画面遷移や処理で他のクラスのコントロールを担うクラス。
• エンティティ（Entity）
  永続化する必要がある情報を表すクラス。ドメインモデルのクラスから選択する。

バウンダリ（Boundary）、コントロール（Control）、エンティティ（Entity）を合わせて「BCE」と言います。
なお、この中のコントロールですが、「何をコントロールするか」を決めることによって論理的に分割することができます。
例えば、次のように考えることができます。

• ユースケース（価値提供の単位）をコントロールする場合、ユースケース単位でコントロールを分ける
• ドメイン（活動領域）をコントロールする場合、ドメイン単位でコントロールを分ける

ここでは、コントロールを、ドメインをコントロールする役割として考えます。
上記「商品の注文」ユースケースを実現するクラスの構造（分析モデル）の例は次のようになります。

バウンダリは、外部設計で作成した画面構成から選択し、エンティティは、要件定義で作成したドメインモデル（クラス図）から選択しています。
なお、「注文明細」エンティティは「注文」エンティティの一部として含まれています。
また、「注文管理」コントロール（真ん中のアイコン）は、「販売」ドメインを管理する役割です。
次に、上記「商品の注文」ユースケースを実現するクラス構造を検証するために作成したシーケンス図の例は次のようになります。

会員アクターからのメッセージを含め、シーケンスの流れは、要件定義で詳細化したユースケースのイベントフローに対応しています。
なお、テスト駆動型開発の場合、ユースケースの内部分析の内容から、UIの振る舞いのインターフェース、および、システムテストのテストケースを実装することができます。

• Product salesOrderUi.selectProduct(String productId);
• salesOrderNo salesOrderUi.confirmSalesOrder([salesOrderDetail]);

クラスの分析

ユースケースを分析した結果、クラス構造の妥当性が確認できたら、クラスの責務を明確にし、クラスの属性と操作を定義します。
具体的には、シーケンス図のメッセージをクラスの操作に割当てます。
上記「商品の注文」ユースケースを実現する分析モデル（クラス図）の例は次のようになります。
ユースケースの内部分析から、上記分析モデル（クラス図）の注文管理の属性と操作を設定すると次のようになります。

データの分析

ドメインモデル（概念データモデル）を論理データモデルへ展開します。
論理データモデルは、次の点を考慮して作成します。

• システムの機能要件を満たすために必要なデータが揃っていること
• データの品質要件（一意性、一貫性など）やセキュリティ要件を満たすための構造になっていること

ER図で描いた論理データモデルの例


記事データモデリング・論理データモデリングも参考にしてください。

設計

設計では、システムのユースケースを実現する物理的な仕組を設計します。
上述したシステム開発の３つのアプローチでいうと次の赤い枠の部分になります。

設計は次のアクションより構成されます。

• アーキテクチャの設計
• ユースケースの設計
• クラスの設計
• データの設計

アーキテクチャの設計

要件定義の非機能要件を受けて、それを実現するための仕組としてのアーキテクチャを設計します。
ここでは、エンタープライズアーキテクチャ（EA）に従って、システムのアーキテクチャを

• アプリケーションアーキテクチャ
• データアーキテクチャ
• テクノロジーアーキテクチャ

に分けて設計します。

テクノロジーアーキテクチャ

テクノロジーアーキテクチャとして、IT（情報技術）基盤の構成を設計します。
IT基盤とは、アプリケーションソフトウェアやデータを支える物理的な基盤で、主に、ネットワーク、ハードウェア、OS、ミドルウェアから構成されます。
なので、例えば、非機能要件のセキュリティ要件を満たすためのネットワーク構成、信頼性要件を満たすためのサーバー構成などを考えます。
また、ミドルウェアとして、非機能要件を満たすためのデータベース管理システム（DBMS）、Webサーバー、アプリケーションサーバー、プログラム言語、アプリケーションフレームワークなどの構成を考えます。
例えば、Javaの代表的なアプリケーションフレームワークにSpringフレームワークがあります。
Springフレームワークの例

• Spring Security
  認証・アクセス制御のためのフレームワークです。
• Spring Batch
  バッチ処理開発のためのフレームワークです。
• Spring Data
  データアクセス・永続化処理の為のフレームワークです。
  リレーショナルデータベースやNoSQLに対応しています。
• Spring Session
  セッション管理のためのフレームワークです。
• Spring Cloud
  分散システム開発のためのフレームワークです。
• Spring MVC
  MVCパターンを提供するためのフレームワークです。

上記「商品の注文」ユースケースを実現する注文管理システムのテクノロジー構成の例は次のようになります。

この例の場合、サーバーの構成を、画面の表示などクライアントに直接関係するフロントエンドサーバーと、ビジネスロジックやデータの永続化を担うバックエンドサーバ−に分けています。
※連携する外部システムは除いています。

データアーキテクチャ

ここでは、データアーキテクチャとして物理データモデルを設計します。
全社レベルのデータアーキテクチャがある場合、それを踏襲します。
なお、物理データモデルに関しては、記事データモデリング・物理データモデリングを参照してください。

アプリケーションアーキテクチャ

アプリケーションソフトウェアのアーキテクチャを次の観点で設計します。

• サブシステムの設計
• 汎用メカニズムの設計

サブシステムの設計

次の３階層のレイアを設けてサブシステムを設計します。

• アプリケーション固有レイア
  今回開発するアプリケーションのレイアです。
• アプリケーション汎用レイア
  既にある外部システムを汎用的に利用する場合、アプリケーション汎用レイアのサブシステムとします。
• ミドルウェアレイア
  アプリケーションフレームワークなど、アプリケーションが使うミドルウェアをミドルウェアのサブシステムとします。

アプリケーションレイアのサブシステムは、分析の際、洗い出されたドメインをベースに考えます。
サブシステムは、ドメイン駆動設計のコンテキスト境界に該当します。
コンテキスト境界は、システムの問題領域を表すドメインに対する解決領域になります。
また、サブシステムは、IT基盤にデプロイする単位であり、マイクロサービスの単位になります。
分析工程で洗い出したドメインからサブシステムを設計すると次のようになります。

この例の場合、

• 「顧客管理」システムと、「商品管理」システムは、既存の外部システムを活用する
• アプリケーションフレームワークとして、Spring DataとSpring MVCを使う

という設計になっていることがわかります。
なお、サブシステムは、他のサブシステムのインターフェース（丸いアイコン）に対して依存しています。
上記システムをモデル化する３つの視点の外部的視点で説明したように、インターフェースと、その実現を分離することによって実装部分がカプセル化され、モジュールとしての再利用性が上がります。
コンテキスト境界を表すサブシステムを、適用したアーキテクチャパターン（下記参照）によってさらに下位のサブシステムに分けることができます。

汎用メカニズムの適用
汎用メカニズムとは、非機能要件などシステムに求められる要件を解決するための汎用的な機構のことです。
汎用メカニズムとして適用されるものとして、

• デザインパターン
  システム開発で発生する汎用的な問題に対する設計上解決策をカタログ化したもの。
• アーキテクチャパターン
  デザインパターンを組み合わせたもので、アプリケーションアーキテクチャ全体に適用できる汎用メカニズム。

があります。
デザインパターンに関しては次の記事を参照してください。
デザインパターンとは
ソフトウェアの設計原則①SOLIDの原則
ソフトウェアの設計原則②コマンド・クエリ分離の原則（CQS）
ソフトウェアの設計原則③GRASP
アーキテクチャパターンに関しては、「ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン」が参考になります。

よく適用されるアーキテクチャパターンの一つのMVCパターンがあります。
MVCはソフトウェアを次のModel、View、Controllerの3要素に分割し、ViewやControllerをModelから切り離すことによって保守性を上げるとともにアプリケーションの中核であるModelの再利用性を上げるというものです。

• Model
  アプリケーションの核となるデータと、それに対する処理を担う。
• View
  Modelの情報をユーザーに表示する。
• Controller
  Viewから取得したイベントをModelやViewに対する要求に変える。

分析のときに適用したBCEを、設計でMVCに変換する場合、次のような例が考えられます。

この例では、Spring MVCのJSPやServletが適用されています。
MVCに関しては次の記事を参照してください。
MVCとは【本来の仕組を詳しく解説】
MVC vs MVC2
MVC vs MVVM
さて、先程、サブシステムをレイア構造で設計しましたが、これもレイアパターンというアーキテクチャパターンになります。

書籍「実践ドメイン駆動設計」では、ドメインモデルを中心にしたヘキサゴナルアーキテクチャというパターンが紹介されています。
ヘキサゴナルアーキテクチャは、フロントエンド（前）とバックエンド（後）という考え方をせず、ドメインモデルを中心に、「内部」と「外部」という考え方をし、どのようなクライアントがきてもアダプタを追加するだけで接続できるようにするというアプリケーションアーキテクチャです。
さまざまな型の外部要素が、それぞれ自分ようのアダプターを持っており、それがアプリケーションのAPIに合わせた形式に入力を変換します。
六角形（ヘキサゴン）の各辺が、それぞれ別の種類のポートを表し、入力あるいは出力に対応しています。
アプリケーションのAPIは、内部要素に対するインターフェースとなり、システムの機能要件（ユースケース）ごとに設計されます。
ヘキサゴナルアーキテクチャを採用することで、ドメインモデルを中心としたドメイン駆動設計と、ユースケースを中心としたユースケース駆動開発を平行して実施することが容易になります。

このドメイン駆動設計ですが、これは、問題解決の対象領域（ドメイン）のソフトウェアモデル（ドメインモデル）をベースに設計、実装を進めるという設計思想です。
ドメインモデルを構成する要素には、ドメインオブジェクト（エンティティ、値オブジェクト）、ドメインサービス、および、ドメインオブジェクトのライフサイクルを管理する集約、ファクトリ、リポジトリがあり、開発者は、これらの要素を適用して、ドメインモデルを設計し、それを実装します。
次の図は、ヘキサゴナルアーキテクチャとMVCパターンを比較した図です。

なお、多くの汎用メカニズムは、アプリケーションフレームワークに内包されているので、アプリケーションフレームワークを使うことによって比較的簡単に適用することができます。

ユースケースの設計

下図の赤い枠のように、分析モデルを、設計レベルのクラス図とシーケンス図（設計モデル）に変換し、設計モデルのクラス構造でユースケースが実現されるか検証します。

上記「商品の注文」ユースケースを実現する設計モデル（クラス図）の例は次のようになります。


また、設計モデル（シーケンス図）の例は次のようになります。


なお、テスト駆動開発の場合、シュースケースの設計の内容から、クラスのインターフェース、および、統合テストのテストケースを実装することができます。
salesOrderNo salesOrderApplicationService.conformSalesOrder([salesOrderdetail])｛
Customer customer = customerRepository.getCustomer(customerId);
Product product = productRepository.getProduct(productId);
SalesOrderId salesOrderNo = salesOrderRepository.nextIdentity();
SalesOrderDetail salesOrderDetail = new SalesOrderDetail(salesOrderNo,salesOrderDate,product,price,quantity);
SalesOrder salesOrder = new SalesOrder(salesOrderId, customer, salesOrderDetails);
salesOrderRepository.save(salesOrder);
//非同期メッセージング
SalesOrderSender.send([salesOrderdetail]);
return salesOrderNo;
｝

クラスの設計

ユースケースを設計した結果、クラス構造の妥当性が確認できたら、クラスの責務を明確にし、クラスの属性と操作として割当てます。
ユースケースの設計から、上記設計モデル（クラス図）のSalesOrderManagementの属性と操作を設定すると次のようになります。

データの設計

論理データモデルからテーブルを定義します。
テーブル定義の例

実装

設計の結果を受けてシステムを実装します。
実装は次のアクションより構成されます。

• IT基盤の構築
• データベースの構築
• アプリケーションの実装
• データの実装

IT基盤の構築

テクノロジーアーキテクチャの結果を受けて、開発環境、テスト環境、本番環境のIT基盤を構築します。
反復型開発では、アーキテクチャを設計する推敲フェーズで、開発環境のIT基盤を構築します。

データベースの構築

テクノロジーアーキテクチャ、および、データアーキテクチャの結果を受けて、開発環境、テスト環境、本番環境のデータベースを構築します。
反復型開発では、アーキテクチャを設計する推敲フェーズで、開発環境のデータベースを構築します。

アプリケーションの実装

ここでは、設計の結果をソースコードに展開し、単体テストで、その妥当性をで検証します。
アプリケーションの実装は次のアクションより構成されます。

• アーキテクチャの実装
• システムの統合
• サブシステムの実装
• クラスの実装
• 単体テストの実行

アーキテクチャの実装

アーキテクチャの実装では、クラスの設計で抽出された設計クラスをテクノロジーアーキテクチャで設計されたIT基盤にマッピングします。
上記「商品の注文」ユースケースを実現する注文管理システムの場合、次のようになります。

※連携する外部システムは除いています。
この例の場合、SalesOrderMangement.warやSalesOrderMangement.jarのように設計クラスをIT基盤にデプロイ（配置）できる単位にアーカイブしています。
JAR（Java Archive）とは、コンパイルされた複数のJavaバイトコード及びそれが使用する画像などのリソースを一つにまとめZIP形式で圧縮されたファイルのことです。
WARファイルは、JavaベースのWebアプリケーションに関係するや複数のJavaバイトコード及びそれが使用する画像などのリソースを一つにまとめZIP形式で圧縮されたファイルのことで、Webサーバ上で動作するものです。
Javaのソースコードやバイトコードなどアプリケーションに関係する物理的なファイルやパッケージをアプリケーションコンポーネントといいます。
アプリケーションコンポーネントの種類には次のようなものがあります。

• 実行可能ファイル
• ソースコード（データ含む）
• ライブラリ
• データベースのテーブル
• ドキュメント（仕様書類）

上の例の場合、JSPやServletなどユーザーインターフェースや画面の制御をするアプリケーションコンポーネントをフロントエンドサーバーに配置し、ビジネスロジックやデータアクセスを制御するアプリケーションコンポーネントをバックエンドサーバーに配置しています。

システムの統合

ここでは、ビルドを統合する計画を立て、ビルドを実行します。
ビルドとは、システムの実行可能バージョンです。
プログラム言語がJavaの場合、ビルドは、上記SalesOrderMangement.warやSalesOrderMangement.jarのように、IT基盤にデプロイできる単位にアーカイブして統合します。
サブシステムの設計のところで説明したように、アプリケーションのサブシステムが、アプリケーション固有レイア、アプリケーション汎用レイア、ミドルウェアレイアなどのようにレイア構造になっている場合、下位のレイアのサブシステムからビルドを統合します。
ミドルウェアレイアのアプリケーションコンポーネントは、適用したフレームワークのライブラリとして提供されています。
アプリケーション固有レイアのビルドは、外部設計で設計したユースケース記述を実現する単位で統合します。
なので、ビルドの統合テストは、このユースケース記述をベースに行われます。
反復単位に一つ以上のビルドの計画を立て、継続してビルドを統合することを「漸増的統合（incremental ingegration）」、または、「継続的統合（continuous integration）」といいます。
漸増的統合によって小刻みにビルドを統合することで、環境の変化に対してシステムをアジャイル（機敏）に適応させることができます。

サブシステムの実装

設計時に考えられたサブシステムを、ディレクトリなど物理的な単位として実装します。
Javaの場合、Javaのパッケージとして実装します。
例えば、上記「商品の注文」ユースケースを実現する注文管理システムのサブシステムのパッケージ構成は次のようになります。
com.company1.sales_management.sales
com.company1.sales_management.customer
com.company1.sales_management.product
com.company1は会社のドメイン名、sales_managementはアプリケーション名を表しています。

【ヘキサゴナルアーキテクチャによるサブシステムの実装】
コンテキスト境界を表すサブシステムを一つのマイクロサービスとして実装するときなど、サーブシステムをさらに下位のサブシステムに分けることができます。
例えば、ヘキサゴナルアーキテクチャによってサブシステムを分けると、次のようにJavaパッケージとして実装することができます。

• application.service
  アプリケーションサービスを格納する。
  さらに各ドメインで分ける。
  インターフェースと実装を分けるときは.implに実装を格納する。
• domain.service
  ドメインサービスを格納する。
  さらに各ドメインで分ける。
  インターフェースと実装を分けるときは.implに実装を格納する。
• domain.model
  ドメインモデルを格納する。
  さらに各ドメインで分ける。
  ドメインごとのエンティティ、値オブジェクト、ファクトリを格納する。
  インターフェースと実装を分けるときは.implに実装を格納する。
• adapter
  さらに以下のように分ける。
  • db
    さらにrdb、nosqlで分ける。
    リポジトリを格納する。
  • messaging
    EventやSender、Receiverを格納する。
  • rest
    RectControllerやRestTemplateを格納する。

クラスの実装

クラスの実装とは、設計クラスを、ソースコードなどのアプリケーションコンポーネントとして実装することです。
上記SalesOrderManagementクラスの実装例は次のようになります。

単体テストの実行

単体テストの目的は、ソースコードを個別にテストすることです。
単体テストには次の種類があります。

• 仕様テスト（specification testing）
  外部的に観察できるソースコードの振舞を検証します。
  ブラックボックステストとも呼びます。
• 構造テスト（structure testing）
  ソースコードの内部的な実装を検証します。
  ホワイトボックステストとも呼びます。
  ソースコードの中にプログラムが満たすべき仕様についての記述を盛り込む事で設計の安全性を高める技法に、契約による設計（Design By Contract）があります。

データの実装

テーブル定義に基づいてDDL（Data Definition Language）でテーブルを実装します。。
商品エンティティをPostgreSQLのDDLで定義した例は次のようになります。

テスト

システムが要件を満たし、業務で運用できるか検証します。
テストは次のアクションより構成されます。

• 統合テスト
• システムテスト
• 運用テスト

統合テスト

統合テストは、ビルド単位に行うもので、開発者が、ビルドが関係するシステムの要件を満たしているか検証します。
統合テストは次のアクションより構成されます。

• テストの立案
• テストの設計
• テストの実装
• テストの実行
• テストの評価

テストの立案

統合テストの立案は、反復の中での作業計画を次の観点で立てることです。

• テストの方針・目標
• テスト作業に必要な要員やシステムリソース
• テスト作業のスケジュール

テストの設計

統合テストを設計する目的は次のようになります。

• 各ビルドのテストケースを洗い出す
  テストケースは、統合テストをする方法を指定するもので、テストを行う際の入力と結果およびテストを実行する際の条件などを記述します。
  テストケースは、ユースケースをベースに作成します。
• 回帰テストケースを設計する
  前回のビルドのテストケースの一部を回帰テストとして使用します。
• テストケースを実行する方法を指定するテストプロシージャを洗い出して編成する
  テストプロシージャは、テストケースを実行する方法（テストケースの中身）を具体的に記述します。
  テストプロシージャは、ユースケース記述をベースに作成します。

テストの実装

テストを実装する目的は、テストコンポーネントを作成し、テストプロシージャを自動化することです。
すべてのテストプロシージャが自動化できるわけではありません。

テストの実行

テスト作業のスケジュールに従って、テストケース単位にテストプロシージャを実行します。

テストの評価

テストの実行作業を評価します。
テスト計画にある目標とテスト結果を比較してテスト作業の結果を評価します。
システムの品質レベルを判定し、さらにどの程度のテストが必要であるかを次の観点で評価します。

• テストの完全性
  テストケースのカバレージと、テストされたアプリケーションコンポーネントのカバレージからテストの完全性を評価します。
• テストの信頼性
  検出された欠陥の傾向の分析結果と、実行結果が期待通りの結果と一致したテストの傾向からテストの信頼性を評価します。

システムテスト

システムテストは、反復の最後に行うもので、開発者が、システム全体として、システムの要件を満たしているか検証します。
システムテストが終了した時点で、システムのベータ版がリリースされます。
システムテストは次のアクションより構成されます。

• テストの立案
• テストの設計
• テストの実装
• テストの実行
• テストの評価

テストの立案

システムテストの立案は、反復の最後に作業計画を次の観点で立てることです。

• テストの方針・目標
• テスト作業に必要な要因やシステムリソース
• テスト作業のスケジュール

テストの設計

システムテストの設計も統合テストと同様の内容ですが、システム全体のテストとして次の点を加味して設計します。

• インストールテスト（installation test）
  システムを顧客のプラットフォームにインストールでき、正しく操作できるか検証します。
• 構成テスト（configuration test）
  異なったネットワーク構成など、システムが異なった構成で正しく動作できるか検証します。
• ネガティブテスト（negative test）
  システムの弱点を表面化させるために、誤ったネットワーク構成で使うなど、システムに異常終了を引き起こすようにし、どのような挙動になるか確認します。
• ストレステスト（stress test）
  コンピュータリソースが不十分なときやリソースを競合するときにシステムに発生する問題を洗い出します。

テストの実装

システムテストのためのテストコンポーネントを作成し、テストプロシージャを自動化します。

テストの実行

統合テストと同様、テストを実行します。

テストの評価

統合テストと同様、テストを評価します。

運用テスト

ユーザーが、システムを使って業務が運用できるか検証します。
要件定義の際、業務フローが作成されていれば、業務フローから運用テストのテストケースを作成します。
運用テストが終了した時点で、システムの完成版（バージョン１）がリリースされます。

システム開発のフェーズ

最後に、統一ソフトウェア開発プロセスの開発フェーズ（横軸）について解説します。

ここでは、システム開発のフェーズを次のように分けて説明します。

1. 方向づけフェーズ
2. 推敲フェーズ
3. 構築フェーズ
4. 移行フェーズ

システム開発の工程とフェーズの関係は次のようになります。

紫色の部分がメインの工程、ピンク色の部分がメインを補完するためのサブ工程です。

方向づけフェーズ

方向づけフェーズの目標は、システムを開発する正当性について確証を得ることです。
要件定義を通して、システム開発に関する主要なリスク（不確実性）を洗い出し、それをどうコントロールするか検討します。
システム開発の主なリスクは次のようになります。

• 要求リスク
  システムに対する要求に関する誤解などによるリスク。
• 技術リスク
  安定性、設計技術、運用と干渉、製品サポート、将来性などによるリスク。
• 要員リスク
  適切な人材の確保や教育、チームワークや適性などによるリスク。
• 政治リスク
  プロジェクトの利害関係者の圧力や対立からの干渉などによるリスク。

システムの目的、要件、リスク・コントロールの検討結果を受けて、体制、コスト、作業に関するプロジェクト計画（概要レベル）を立案します。

推敲フェーズ

推敲フェーズの目標は、システムの土台となるアーキテクチャを確立することです。
アーキテクチャに基づいて、開発要員の配分、コストの詳細見積もりを行いプロジェクト計画（詳細レベル）を完成させます。

構築フェーズ

構築フェーズの目標は、アーキテクチャ（骨格）に基づいてシステムを実装（肉付）し、システムテストを通してシステムのベータ版をリリースすることです。

移行フェーズ

移行フェーズの目標は、運用テストを通して、システムのベータ版を完成版に移行し、システムを使って業務活動を遂行できる状態にすることです。
データの移行が必要な場合、移行ためのプログラムも作成します。
なお、移行フェーズでは、システムの操作教育、システム運用・保守体制の整備などシステムを使って業務活動を遂行できるするための活動も行います。

【関連動画】