ソフトウェアを開発する手法がソフトウェア開発プロセスです。 システム開発プロセス、開発工程などとも呼ばれます。
V字モデル
ソフトウェア開発のプロセスはV字モデルで表現されます。 プロセスは手法であり、適用するプロジェクトによって呼び方や内容が変わるのですが、だいたいは以下の構造をしています。
矢印は進む方向です。 アジャイル開発の場合もユーザーストーリーごとにこれらのステップを踏むだけで、基本は同じです。 左側については部分的に次工程以降の作業も並行で実施することも多いでしょう。
V字モデルの優れている点は、各工程でどんな作業をしなければならないかが明確に分かる点です。 左側の各工程の対として、必ずテストが組み込まれていることから分かるように、左側の各工程を完了する際に、右側のテストが可能になっているようにしなければなりません。
ウォーターフォール開発とアジャイル開発
現在主流なソフトウェア開発プロセスの種類には、ウォーターフォール開発とアジャイル開発の2つがあります。 ただ、一般的に言われるような単純な違いではないので、簡単に紹介しておきます。
ウォーターフォール開発
1976年の論文で初めてウォーターフォールの単語が出てきたということですが、その起源ははっきりしないようです。 1970年のWinston Royce博士の論文に似た図があるため、博士が提唱者であるといわれることもありますが、論文の内容はウォーターフォール開発での失敗をなくす方法を述べたものであり、単純なウォーターフォール開発をすべきというものではありません。
博士が提唱している方法は以下の5つです。
- プログラム設計を先に行う
- 設計ドキュメントを重視する
- 2回開発する
- テストを重視する
- 顧客を巻き込む
特に、1.と3.については、一般的には知られていないことなのではないかと思います。 ただし、優れた開発者であれば、経験的に知り、実施していることかと思います。
起源はともかく、ウォーターフォール開発は決められたQCDを達成する手法ということが言えそうです。 QCDを変えずに開発をするのがウォーターフォール開発という理解でまずはよいかと思います。 一般的なプロジェクトではまず予算が決まり、それに基づいてQCDを決めますので、ウォーターフォール開発になることが多いでしょう。
- [1] Winston Royce「MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS」 - http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
アジャイル開発
アジャイル開発とは、アジャイルソフトウェア開発宣言とアジャイル ソフトウェアの 12 の原則に則った開発のことです。 元々は、エクストリーム・プログラミング、スクラムといった先進的なプラクティスをまとめるためのコンセプト、文化の定義として始まりました。
一般的に言われている単純なウォーターフォール開発との差異だけでなく、概念的なトピックを多く含みます。 詳しくは、以下のようなガイドを参照するとよいと思います。
アジャイル開発では必ずしもプロジェクト開始時に決めたQCDを是としません。 QCDすべてを変化させることのできる開発がアジャイル開発と言えるのではないかと思います。 そういった意味で、受託開発でアジャイル開発を実施するのはかなりハードルが高いものになります。 その場合、業務委託として実施する場合が多いのではないかと思います。
- [1] アジャイルソフトウェア開発宣言 - https://agilemanifesto.org/iso/ja/manifesto.html
- [2] アジャイル ソフトウェアの 12 の原則 - https://agilemanifesto.org/principles.html
各工程の説明
V字モデルの各工程の内容を簡単に説明します。
要求分析
To-Beの業務の構想と実現するシステムの構想を行ないます。 通常、プロジェクトが開始する前に実施する作業なので、工程を明確に意識することはないかもしれません。 投資対効果を判断するフェーズで、超上流工程とも呼ばれます。 要件定義を一部実施する場合も多いです。 RFP・提案書・業務フロー・見積・プロジェクト計画書などがアウトプットになります。
要件定義
機能要件・非機能要件を定義します。 プロジェクト開始前に実施できるのが理想ですが、要件を決定するというかなり重たい作業なので、準委任契約で実施したり、プロジェクト開始後に実施することになる場合も多いです。 要件を達成するためのシステム設計・検証も行います。 この工程から基本設計・詳細設計との境界があいまいになりがちです。 境界をどう見極めるかは、正直、経験に大きく左右されると思います。 要件定義書などががアウトプットになります。
基本設計
機能仕様やシステムの振る舞いや構造を定義します。 機能仕様書・基本設計仕様書などががアウトプットになります。
詳細設計
昔は関数仕様書などを作成したりしましたが、仕様書の自動生成・自動テストに統合されたりして、最近はこの工程を実施することは少なくなったかもしれません。 詳細設計仕様書などがアウトプットになります。
実装
ソースコードを書く作業です。 テストコードを書いたり、デバッグをする作業も含まれます。
単体テスト
詳細設計で定義した仕様をテストします。 テストのコード化によって、詳細設計・実装・単体テストまでを一連の工程として実施することも多くなりました。 ユニットテストとも呼ばれます。 また、サブシステム化やモジュール化されている場合は、それぞれのサブシステム・モジュールのテストをすることを単体テストと呼ぶこともあります。
結合テスト
基本設計で定義した仕様をテストします。 機能テスト、統合テストとも呼ばれます。 この段階までは開発環境でテストします。
システムテスト
要件定義で定義した仕様をテストします。 ユースケースに沿ったシナリオのテストなどを実施します。 運用テストを含む場合もあります。 プロジェクトによりますが、普通はステージング環境でテストします。
受入テスト
要求分析で構想した内容をテストします。 UAT(User Acceptance Test)とも呼ばれます。 受入というと、請負開発における検収としての意味合いが強くなりますが、そもそもの目的を達成できているかを確認する大事な工程です。 プロジェクトによりますが、普通は本番環境でテストします。